Docs
Pricing
Explore
Search...
⌘
K
Log in
Sign up
Toggle menu
Home
jjmoore1970
makesolid
public
Published on 6/22/2025
make solid
[R] SOLID Design Principles - Coding Assistant Guidelines {copy of Continue.dev}
Rules
Star
0
Add block
Preview
Markdown
[R] SOLID rules
When generating, reviewing, or modifying code, follow these guidelines to ensure adherence to SOLID principles:
1. Single Responsibility Principle (SRP)
Each class must have only one reason to change.
Limit class scope to a single functional area or abstraction level.
When a class exceeds 100-150 lines, consider if it has multiple responsibilities.
Separate cross-cutting concerns (logging, validation, error handling) from business logic.
Create dedicated classes for distinct operations like data access, business rules, and UI.
Method names should clearly indicate their singular purpose.
If a method description requires "and" or "or", it likely violates SRP.
Prioritize composition over inheritance when combining behaviors.
2. Open/Closed Principle (OCP)
Design classes to be extended without modification.
Use abstract classes and interfaces to define stable contracts.
Implement extension points for anticipated variations.
Favor strategy patterns over conditional logic.
Use configuration and dependency injection to support behavior changes.
Avoid switch/if-else chains based on type checking.
Provide hooks for customization in frameworks and libraries.
Design with polymorphism as the primary mechanism for extending functionality.
3. Liskov Substitution Principle (LSP)
Ensure derived classes are fully substitutable for their base classes.
Maintain all invariants of the base class in derived classes.
Never throw exceptions from methods that don't specify them in base classes.
Don't strengthen preconditions in subclasses.
Don't weaken postconditions in subclasses.
Never override methods with implementations that do nothing or throw exceptions.
Avoid type checking or downcasting, which may indicate LSP violations.
Prefer composition over inheritance when complete substitutability can't be achieved.
4. Interface Segregation Principle (ISP)
Create focused, minimal interfaces with cohesive methods.
Split large interfaces into smaller, more specific ones.
Design interfaces around client needs, not implementation convenience.
Avoid "fat" interfaces that force clients to depend on methods they don't use.
Use role interfaces that represent behaviors rather than object types.
Implement multiple small interfaces rather than a single general-purpose one.
Consider interface composition to build up complex behaviors.
Remove any methods from interfaces that are only used by a subset of implementing classes.
5. Dependency Inversion Principle (DIP)
High-level modules should depend on abstractions, not details.
Make all dependencies explicit, ideally through constructor parameters.
Use dependency injection to provide implementations.
Program to interfaces, not concrete classes.
Place abstractions in a separate package/namespace from implementations.
Avoid direct instantiation of service classes with 'new' in business logic.
Create abstraction boundaries at architectural layer transitions.
Define interfaces owned by the client, not the implementation.
Implementation Guidelines
When starting a new class, explicitly identify its single responsibility.
Document extension points and expected subclassing behavior.
Write interface contracts with clear expectations and invariants.
Question any class that depends on many concrete implementations.
Use factories, dependency injection, or service locators to manage dependencies.
Review inheritance hierarchies to ensure LSP compliance.
Regularly refactor toward SOLID, especially when extending functionality.
Use design patterns (Strategy, Decorator, Factory, Observer, etc.) to facilitate SOLID adherence.
Warning Signs
God classes that do "everything"
Methods with boolean parameters that radically change behavior
Deep inheritance hierarchies
Classes that need to know about implementation details of their dependencies
Circular dependencies between modules
High coupling between unrelated components
Classes that grow rapidly in size with new features
Methods with many parameters