SOLID

May 10, 2026··
13 min read
Open full tree
SOLIDIntroduction to SOLIDSingle Responsibility PrincipleOpen-Closed PrincipleLiskov Substitution PrincipleInterface Segregation PrincipleDependency Inversion PrincipleApplying SOLID PrinciplesTesting SOLID Principles

SOLID: A Deep Dive into Object-Oriented Design Principles

Abstract

SOLID is a set of five design principles that guide the creation of maintainable, extensible, and testable object-oriented software. Introduced and popularized by Robert C. Martin ("Uncle Bob") and grounded in earlier formal work (notably Barbara Liskov’s work on substitutability), SOLID encapsulates essential ideas about cohesion, coupling, abstraction, and dependency management. This article examines the history, theory, practical application, code examples, limitations, and future directions of SOLID. It also shows how SOLID interacts with modern architectures—microservices, domain-driven design (DDD), functional programming paradigms—and automated tooling.

Table of contents

  • History and Origins
  • Overview of the Principles
    • Single Responsibility Principle (SRP)
    • Open/Closed Principle (OCP)
    • Liskov Substitution Principle (LSP)
    • Interface Segregation Principle (ISP)
    • Dependency Inversion Principle (DIP)
  • Theoretical Foundations
    • Cohesion and Coupling
    • Behavioral Subtyping and Liskov’s Formalism
    • Abstraction and Information Hiding
  • Practical Applications and Design Patterns
    • Unit Testing and Testability
    • Dependency Injection and IoC Containers
    • Patterns that Support SOLID
    • Architecture-level Patterns: Clean Architecture, Hexagonal, Layered
  • Examples and Code
    • SRP examples (before / after)
    • OCP examples (open for extension)
    • LSP examples (behavioral substitutions)
    • ISP examples (interface segregation)
    • DIP examples (high-level modules and abstractions)
  • Common Misapplications, Anti-patterns, and Trade-offs
  • Measuring & Enforcing SOLID
  • SOLID Beyond OOP: Functional, Distributed, and Microservice Contexts
  • Current State, Trends, and Future Directions
  • Practical Checklist & Refactoring Recipes
  • Conclusion
  • Suggested References

History and Origins

  • SOLID acronym was coined by Michael Feathers but popularized by Robert C. Martin (Uncle Bob) in the early 2000s as a concise way to remember five core object-oriented design principles.
  • Origins tie into older, foundational ideas:
    • Single Responsibility echoes separation of concerns (E. W. Dijkstra and others).
    • Liskov Substitution Principle formalizes substitutability (Barbara Liskov, 1987).
    • Interface Segregation and Dependency Inversion were influenced by modularization practices and the push for greater decoupling in software systems.
  • Over time SOLID became a central teaching tool in software engineering, guiding both day-to-day code decisions and larger architecture choices.

Overview of the Principles

Single Responsibility Principle (SRP)

  • Definition: A class should have one, and only one, reason to change.
  • Intent: Maximize cohesion; minimize coupling by ensuring every module/actor has a single responsibility.
  • Rationale: When responsibilities are mixed, changes for one reason can introduce bugs affecting another. Smaller, focused units are easier to test and refactor.
  • Common code smell: God classes or classes that do persistence, business logic, and formatting at once.

Example (Java-like pseudocode — violation):

Plain Text
1class InvoiceManager { 2 void calculateTotals(Invoice invoice) { ... } // business logic 3 void saveInvoice(Invoice invoice) { ... } // persistence 4 void printInvoice(Invoice invoice) { ... } // UI/formatting 5}

Refactor (SRP applied):

Plain Text
class InvoiceCalculator { ... } class InvoiceRepository { ... } class InvoicePrinter { ... }

Open/Closed Principle (OCP)

  • Definition: Software entities (classes, modules, functions) should be open for extension, but closed for modification.
  • Intent: Allow system behavior to be extended without altering existing tested code, reducing regression risk.
  • Rationale: Use abstraction, polymorphism, and composition to add features without touching stable code.
  • Common code smell: Large conditional statements (if/else, switch) that require editing for new behaviors.

Example (violation):

Plain Text
1class DiscountService { 2 double applyDiscountOrder(Order o) { 3 if (o.type == OrderType.REGULAR) return o.total * 0.95; 4 if (o.type == OrderType.PREMIUM) return o.total * 0.90; 5 // adding new types requires editing this class 6 } 7}

Refactor (OCP applied using strategy pattern):

Plain Text
1interface DiscountPolicy { double apply(Order o); } 2class RegularDiscount implements DiscountPolicy { ... } 3class PremiumDiscount implements DiscountPolicy { ... } 4 5class DiscountService { 6 DiscountPolicy policy; 7 double applyDiscount(Order o) { return policy.apply(o); } 8}

Liskov Substitution Principle (LSP)

  • Definition: Objects of a superclass should be replaceable with objects of a subclass without altering the desirable properties of the program (correctness, task performed).
  • Intent: Subtypes must honor the contract of supertypes—behavioral compatibility matters, not just method signatures.
  • Rationale: Inheritance should preserve behavior; violating it causes subtle bugs when substituting instances.
  • Common code smell: Subclasses overriding behavior in a way that changes expectations (e.g., throwing unexpected exceptions or breaking invariants).

Classic example (Rectangle-Square problem):

Plain Text
1class Rectangle { 2 int width, height; 3 void setWidth(int w) { width = w; } 4 void setHeight(int h) { height = h; } 5} 6class Square extends Rectangle { 7 void setWidth(int w) { width = height = w; } // breaks LSP 8 void setHeight(int h) { width = height = h; } 9}

Using a Square where Rectangle is expected may violate invariants and client code expectations.

Interface Segregation Principle (ISP)

  • Definition: Clients should not be forced to depend on interfaces they do not use. Provide many client-specific interfaces instead of one general-purpose interface.
  • Intent: Reduce coupling between clients and large, fat interfaces.
  • Rationale: Smaller interfaces lead to clearer contracts and easier mocking/testing.
  • Common code smell: Large interfaces that require classes to implement methods not relevant to them.

Example (violation):

Plain Text
1interface MultiDevicePrinter { 2 void print(Document d); 3 void scan(Document d); 4 void fax(Document d); 5} 6 7class SimplePrinter implements MultiDevicePrinter { 8 void print(Document d) { ... } 9 void scan(Document d) { throw new UnsupportedOperationException(); } 10 void fax(Document d) { throw new UnsupportedOperationException(); } 11}

Refactor (ISP applied):

Plain Text
1interface Printer { void print(Document d); } 2interface Scanner { void scan(Document d); } 3interface Fax { void fax(Document d); } 4 5class SimplePrinter implements Printer { ... }

Dependency Inversion Principle (DIP)

  • Definition: High-level modules should not depend on low-level modules; both should depend on abstractions. Abstractions should not depend on details; details should depend on abstractions.
  • Intent: Invert conventional dependency flow so design depends on stable interfaces, not volatile implementations.
  • Rationale: Makes high-level policy independent of low-level implementation details; facilitates swapping implementations and testing.
  • Common code smell: High-level class instantiates low-level concrete classes directly.

Example (violation):

Plain Text
1class UserService { 2 private UserRepository repo = new SqlUserRepository(); // tight coupling 3 User getUser(String id) { return repo.find(id); } 4}

Refactor (DIP via constructor injection):

Plain Text
1interface UserRepository { User find(String id); } 2 3class UserService { 4 private final UserRepository repo; 5 UserService(UserRepository repo) { this.repo = repo; } 6 User getUser(String id) { return repo.find(id); } 7}

Theoretical Foundations

Cohesion and Coupling

  • Cohesion: Degree to which elements of a module belong together. High cohesion is desired.
  • Coupling: Degree of interdependence between modules. Low coupling is desired.
  • SOLID is fundamentally about increasing cohesion and reducing coupling via modularization, interfaces, and dependency handling.

Behavioral Subtyping (Liskov)

  • LSP is not merely about method signatures—it is about behavior and contracts (preconditions, postconditions, invariants).
  • Formalized through concepts like Design by Contract: a subtype must not strengthen preconditions or weaken postconditions.

Abstraction & Information Hiding

  • SOLID encourages coding to abstractions and hiding implementation details, consistent with classic software engineering principles (Parnas, 1972).

Practical Applications and Design Patterns

Unit Testing and Testability

  • Adherence to SOLID facilitates dependency injection and small focused classes, both improving unit testing and mockability.
  • For example, DIP + constructor injection makes it straightforward to inject test doubles.

Dependency Injection and IoC Containers

  • DI (manual or via an IoC container) is a common technique to realize DIP in production systems.
  • Popular containers: Spring (Java), .NET Core DI, Guice, NestJS (TypeScript), etc.

Patterns that Support SOLID

  • Strategy, Factory, Adapter, Decorator, Bridge, Command, Template Method, Repository, and more—many GoF patterns help satisfy OCP, DIP, ISP and SRP.
  • Composition over inheritance is often recommended to avoid LSP pitfalls and to keep classes open for extension.

Architecture-level Patterns

  • Clean Architecture, Hexagonal Architecture (Ports & Adapters), and Onion Architecture are explicit applications of DIP and SRP: core domain depends on abstractions only; infrastructure depends on core.

Examples and Code

SRP Example (detailed) Violation (JavaScript/TypeScript style):

TypeScript
1class Report { 2 constructor(private data: any[]) {} 3 calculate() { /* complex aggregations */ } 4 toCsv(): string { /* format as CSV */ } 5 saveToFile(path: string) { /* file IO */ } 6}

Refactor:

TypeScript
class ReportCalculator { calculate(data: any[]): any { ... } } class ReportFormatter { toCsv(result: any): string { ... } } class FileSaver { save(path: string, content: string) { ... } }

OCP Example (open for extension) Violation:

Plain Text
1double calculateArea(Shape s) { 2 if (s.type == CIRCLE) return Math.PI * s.radius * s.radius; 3 if (s.type == SQUARE) return s.side * s.side; 4 // add new shapes => modify method 5}

Refactor:

Plain Text
1interface Shape { double area(); } 2class Circle implements Shape { double area() { return ... } } 3class Square implements Shape { double area() { return ... } } 4double calculateArea(Shape s) { return s.area(); } // closed for modification

LSP Example (behavioral) Violation:

Plain Text
class Bird { void fly() { ... } } class Ostrich extends Bird { void fly() { throw new UnsupportedOperationException(); } }

Refactor:

  • Reconsider the inheritance model: extract a Flyable interface; Ostrich does not implement Flyable.

ISP Example (interface segregation) Violation:

Plain Text
1public interface IVehicle { 2 void Drive(); 3 void Fly(); 4 void Sail(); 5} 6public class Car : IVehicle { 7 public void Drive() { ... } 8 public void Fly() { throw new NotImplementedException(); } 9 public void Sail() { throw new NotImplementedException(); } 10}

Refactor:

Plain Text
1public interface IDrivable { void Drive(); } 2public interface IFlyable { void Fly(); } 3public interface ISailable { void Sail(); } 4public class Car : IDrivable { public void Drive() { ... } }

DIP Example (in C#) Violation:

Plain Text
1public class EmailService { 2 private SmtpClient smtp = new SmtpClient(); // direct dependency 3 public void Send(Message m) { smtp.Send(m); } 4}

Refactor:

Plain Text
1public interface IMailClient { void Send(Message m); } 2public class SmtpMailClient : IMailClient { public void Send(Message m) { /* send */ } } 3 4public class EmailService { 5 private readonly IMailClient client; 6 public EmailService(IMailClient client) { this.client = client; } 7 public void Send(Message m) { client.Send(m); } 8}

Common Misapplications, Anti-patterns, and Trade-offs

  • Overuse and Premature Abstraction: Creating interfaces for every class causes complexity and interface proliferation. Apply YAGNI—introduce abstractions when concrete duplication or change needs present themselves.
  • Over-fragmentation (ISP abuse): Creating too many tiny interfaces or classes can make code harder to navigate.
  • Misapplied LSP: Not all use of inheritance is wrong, but inheritance must respect behavior. Prefer composition over inheritance when behavioral substitution is unclear.
  • DIP with Service Locator: Hiding dependencies via a service locator is sometimes considered an anti-pattern because it obscures what a module actually needs.
  • Performance and Pragmatics: Abstraction layers have small runtime costs and may complicate debugging. For performance-critical code, pragmatic deviations may be justified.
  • Increased Indirection: SOLID can increase the indirection and the number of files. Balance is required—readability and team familiarity matter.

Measuring & Enforcing SOLID

  • Static analysis tools & linters: detect large classes, high coupling, and some dependency issues (e.g., SonarQube, Resharper).
  • Metrics:
    • Coupling Between Objects (CBO)
    • Lack of Cohesion of Methods (LCOM)
    • Cyclomatic complexity
    • Maintainability index
  • Code reviews and architectural reviews remain essential to detect design intent and behavior-level LSP issues that tools cannot infer.

SOLID Beyond OOP: Functional, Distributed, and Microservice Contexts

Functional programming

  • Many SOLID goals translate to FP idioms:
    • SRP → small pure functions with single responsibility.
    • OCP → composition of functions and higher-order functions.
    • DIP → pass dependencies as function parameters or closures (higher-order functions).
    • LSP → algebraic data types and strong type systems ensure substitutability at the type level, but behavioral contracts remain a concern.
    • ISP → small, focused interfaces map to small type classes or module signatures.

Microservices & Distributed Systems

  • SRP maps to single-purpose microservices (bounded contexts).
  • OCP is realized by designing services and APIs that can evolve without requiring simultaneous changes across callers (versioning, backward compatibility).
  • DIP in distributed systems often corresponds to protocol abstraction—clients depend on interfaces (API contracts) not a single provider.
  • Practical constraints: network, observability, operational concerns lead to trade-offs (cohesion within services vs. distributed transactions, etc).

Current State, Trends, and Future Directions

  • SOLID remains foundational for maintainable OO codebases but is increasingly integrated with modern architectural approaches:
    • Clean Architecture explicitly uses DIP and SRP to separate business rules from frameworks.
    • Domain-Driven Design (DDD) uses SRP, bounded contexts, and rich domain models.
  • Tooling: improved static analysis, automated refactorings, dependency graphs, and architecture-as-code checks help enforce SOLID at scale.
  • AI and Code Generation: AI-assisted code generation can both help and harm SOLID:
    • Helps by generating idiomatic patterns, tests, and refactorings.
    • Risks generating boilerplate that is antipattern-prone or leads to over-abstraction.
  • Emphasis on composition over inheritance continues: many modern frameworks favor dependency injection, composition, and plugins instead of deep class hierarchies.
  • Formal methods & contracts: Growing interest in specifying behavioral contracts (via types, design-by-contract, formal verification) to make LSP checks more rigorous.

Practical Checklist & Refactoring Recipes

Quick checklist when designing or refactoring:

  • SRP:
    • Does this class have more than one reason to change?
    • Can responsibilities be separated into cohesive classes?
  • OCP:
    • Are there long switch/case chains or if/else cascades? Can they be replaced with polymorphism or strategy?
  • LSP:
    • Will derived classes behave as clients expect? Check preconditions, postconditions, and invariants.
  • ISP:
    • Are interfaces forcing implementers to include methods they don’t need? Can you split the interface?
  • DIP:
    • Do high-level modules depend on concrete lower-level implementations? Can you introduce abstractions and invert dependencies?

Refactoring recipes:

  • Extract Class (SRP)
  • Replace Conditional with Polymorphism (OCP)
  • Extract Interface (ISP, DIP)
  • Introduce Adapter (for LSP or DIP issues)
  • Replace Inheritance with Composition (for LSP issues)

Conclusion

SOLID provides a practical, succinct set of rules to guide object-oriented design toward maintainability, extensibility, and testability. While these principles are invaluable, they are not dogma: apply them judiciously, balancing complexity, readability, and pragmatism. SOLID’s real power is in encouraging thoughtful separation of concerns, reliance on abstractions, and attention to behavioral correctness—foundations that remain relevant as software architecture evolves.

Suggested References

  • Robert C. Martin, "Agile Software Development, Principles, Patterns, and Practices"
  • Barbara Liskov, "Data Abstraction and Hierarchy" and related publications (Liskov Substitution Principle)
  • Erich Gamma et al., "Design Patterns: Elements of Reusable Object-Oriented Software"
  • David Parnas, "On the Criteria to Be Used in Decomposing Systems into Modules"
  • Martin Fowler, "Refactoring" and various writings on software design

If you’d like, I can:

  • Provide a language-specific, runnable example project that demonstrates SOLID principles end-to-end.
  • Generate a refactoring plan for a concrete class or module you supply.
  • Create a checklist or static-analysis rule-set tailored to your language/framework. Which would be most helpful?