Do You Really Understand SOLID Design Principles?

Continuing the series on development principles, the author introduces a three‑layer framework (class‑level, pattern‑level, component‑level) that answers the core question: how should dependencies be directed so that changes do not ripple through the whole system?

Class‑level – SOLID misinterpretations and correct meanings

SRP : The common mistake is to split every public method into its own class, causing a class explosion. Martin redefines SRP in Clean Architecture as “a module should have responsibility for a single actor” – the person or role that requests a change. The judgment question is: “Who would request a change to this class for different reasons?” If both finance and operations need to modify the same report class, the class serves two actors and violates SRP. This focus locks the change direction to a single actor, preventing cross‑actor change propagation.

OCP : Some read OCP as “never modify existing code.” The principle actually originates from Bertrand Meyer (1988) as the “inheritance‑based open‑closed principle” and was later popularized by Robert C. Martin (Martin) as the “polymorphic open‑closed principle.” Meyer’s version relies on inheritance; Martin’s version relies on abstraction and polymorphism, which generally offers more flexibility because composition can replace inheritance. The judgment is whether adding a feature requires new code or modifications to existing code; if the latter, OCP is violated. OCP aligns dependency direction from concrete to abstract, so new implementations depend on stable abstractions without the old code needing to know them.

LSP : The oversimplified view is that a subclass can replace a superclass as long as the method signatures match. The original definition by Barbara Liskov (1987, 1994) requires that a subtype honor the supertype’s behavioral contract: pre‑conditions cannot be stronger, post‑conditions cannot be weaker, and invariants must be preserved. The classic counter‑example is a Square inheriting from Rectangle—changing width also changes height, breaking the rectangle’s contract. The judgment is whether a subclass’s behavior remains consistent with the expectations of code that uses the superclass. When it does, dependency on the superclass remains safe.

ISP : The misconception is that “the more interfaces the better.” The principle arose from Martin’s consulting experience at Xerox, where a “fat interface” forced every printer implementation to support all methods, even those a client never used. ISP actually means “segregate interfaces according to client needs.” If a client is forced to depend on methods it never calls, the interface should be split. This narrows the dependency scope, and together with the Law of Demeter (LoD) limits the spread of dependencies.

DIP : The false belief is that every class needs an interface layer. DIP’s core is that high‑level modules should depend on abstractions, not on low‑level concrete modules, and that “abstraction” does not necessarily mean an interface—stable concrete classes can serve as abstractions. The judgment question is whether a frequently‑changed module depends on a stable abstraction; if business code directly instantiates a concrete database class, a change in the database forces business code to change, indicating a reversed dependency.

Pattern‑level – filling the gap with GRASP

GRASP (General Responsibility Assignment Software Patterns) supplies the missing “who should do what” layer. Its nine patterns are grouped into responsibility assignment, quality assurance, and change protection. For example, the Strategy pattern realizes OCP by letting a context depend on a strategy interface; new strategies are added without modifying the context. The Decorator pattern supports SRP and OCP by adding single‑purpose enhancements without altering the original class. The Adapter pattern embodies ISP by converting a “fat” third‑party interface into a narrow one that the client actually uses.

Component‑level – SOLID grown up

Robert C. Martin extends SOLID from classes to components in Clean Architecture , defining six component principles grouped into cohesion (CCP, CRP) and coupling (SDP, SAP, REP, ADP). CCP (Common Closure Principle) and CRP (Common Reuse Principle) map to SRP+OCP, ensuring classes that change for the same reason are packaged together. SDP (Stable Dependency Principle) and SAP (Stable Abstraction Principle) correspond to DIP, directing dependencies toward stable abstractions. REP (Release Equivalence Principle) and ADP (Acyclic Dependencies Principle) address reuse granularity and dependency cycles. Martin’s tension triangle shows that maximizing REP and CRP increases change impact, while maximizing CCP improves maintainability—there is no perfect solution, only trade‑offs.

Finally, the author suggests using the three‑layer perspective during code reviews: check whether a class’s responsibility is split across actors, whether the chosen pattern serves the appropriate principle, and whether the package’s dependencies point toward stable abstractions.