SOLID — an acronym covering five object-oriented design principles compiled and popularized by Robert C. Martin — is one of the most frequently cited, and most unevenly applied, sets of ideas in software design. Part of the unevenness comes from the acronym compressing five genuinely different ideas, of different scope and different practical value, into one easily quotable package, which tends to flatten real distinctions between them. A related set of design principles is documented in Microsoft architectural principles.
The two letters that do the most work
The Single Responsibility Principle (a class or module should have one reason to change) and the Open/Closed Principle (software entities should be open for extension but closed for modification) are, in practice, the two most broadly useful of the five — both name a genuinely common failure mode (a class accumulating unrelated responsibilities until any change to one risks breaking another; a change that requires modifying existing, working code rather than adding new code alongside it) that shows up across a huge range of systems and languages, well beyond the object-oriented context the acronym was originally framed in. The distinction between ownership and blame is explored further in the linked resource.
The Liskov Substitution Principle (subtypes must be substitutable for their base types without breaking correctness) is more specific and more frequently violated in subtle ways — a classic example being a Square class that inherits from Rectangle but breaks callers that expect to set width and height independently, since a square can't honor both independently. The principle is precise and correct, but requires more design sophistication to apply correctly than the first two, which is part of why violations of it are common even among developers who can state the principle accurately.
The two letters that need more caveats
The Interface Segregation Principle (clients shouldn't be forced to depend on interfaces they don't use) and the Dependency Inversion Principle (depend on abstractions, not concrete implementations) are genuinely useful in the right context — typically larger systems with real, competing implementations or genuinely divergent client needs — but applied reflexively to small, simple systems, they tend to introduce a layer of abstraction and indirection that has a real cost (more files, more indirection to trace through when reading the code) without a corresponding benefit, because the abstraction they're preparing for may never actually be needed.
This is the most common criticism of SOLID as it's actually practiced: treating all five principles as equally and universally applicable, regardless of a system's actual scale and actual need for the flexibility each principle provides, produces unnecessarily abstract code in situations that didn't call for it — abstraction has a cost, and that cost is only worth paying when the flexibility it buys is genuinely needed, not preemptively.
- Single Responsibility and Open/Closed are broadly useful defaults across most codebases, most of the time.
- Liskov Substitution requires real design attention — it's easy to state and easy to accidentally violate through seemingly reasonable inheritance choices.
- Interface Segregation and Dependency Inversion pay off specifically when there are genuinely multiple implementations or genuinely divergent client needs — applied preemptively in their absence, they add cost without benefit.
- None of the five principles is an end in itself — each is a means to a specific, nameable benefit (easier to change, easier to test, easier to substitute), and it's worth being able to state which benefit a given application of the principle is actually buying.
Why the acronym form causes more harm than the ideas themselves
Compressed into a five-letter acronym, SOLID invites recitation more than understanding — it's easy to name all five principles without being able to say, for a specific piece of code, which one actually applies and why. The most common failure isn't violating a SOLID principle; it's applying one of the principles somewhere it doesn't actually help, out of a general sense that following the acronym is inherently good, independent of the specific problem at hand.
Read as a toolkit rather than a checklist, SOLID holds up considerably better than its critics or its most reflexive adopters usually give it credit for — the ideas are sound; the harm comes almost entirely from applying all five uniformly, regardless of context.