SOLID Principles of Object-Oriented Design

SOLID is an acronym coined by Robert C. Martin (Uncle Bob) to name the five core principles of object-oriented design. Each letter maps to one principle: Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion.

The principles connect directly to two structural goals in OOP: high cohesion (each unit does one thing well) and low coupling (units depend on abstractions, not implementations). Code that follows SOLID stays readable, testable, and extensible through the maintenance phase. That phase typically accounts for 80% of a software project's total cost, which is why good design decisions made during development pay off over years.

Also see: Write Better Code.

S: Single Responsibility Principle (SRP)

Each class owns exactly one responsibility. A class designed to read from a database does only that. It does not also format numbers, parse dates, or validate user input.

The temptation to violate SRP is real. When a utility method happens to be convenient inside a class that already exists, developers drop it in. The class then accumulates behavior unrelated to its stated purpose. Finding that behavior later requires knowing where it was placed at the time, not where it logically belongs.

A practical sign of SRP violation: a class that changes for more than one reason. If you modify a persistence class because business rules changed, the class is doing too much. Split it so each piece changes for exactly one reason.

O: Open/Closed Principle (OCP)

Classes are open for extension and closed for modification. Bertrand Meyer introduced this principle to describe designs that accept new behavior without changing existing source code.

Inheritance is the most common extension mechanism. A subclass re-implements a method to specialize behavior without touching the parent class. The alternative is to write methods that accept an interface, allowing any class implementing that interface to plug in. In both cases the class behavior changes without editing its internals.

The hard part of OCP is predicting extension points before you need them. When requirements shift far enough outside what the design anticipated, no extension hook covers the gap and refactoring becomes necessary. That is not a failure of the principle; it is the point where honest assessment of scope matters more than dogma.

L: Liskov Substitution Principle (LSP)

Barbara Liskov defined this principle: every derived class must be usable in place of its base class without altering the correctness of the program.

When you create a subclass, the subclass must not weaken the guarantees the base class provides. If the base class guarantees that a method returns a non-null value, the subclass must also return a non-null value. If the base class accepts any positive integer as input, the subclass cannot impose a stricter constraint. Violations of LSP produce subtle bugs: code that works with the base class breaks silently when a subclass is passed in.

A quick self-check: can you swap every use of the base class with a concrete subclass and have the program behave correctly? If not, the inheritance hierarchy needs redesign.

I: Interface Segregation Principle (ISP)

Robert C. Martin formulated ISP alongside the Dependency Inversion Principle. The rule: prefer many focused interfaces over one broad interface.

Consider an interface that declares both compare() and clone(). A class that only needs comparison is forced to implement clone() as a stub or throw an exception, either of which is misleading. Split the interface into Comparable and Cloneable, and each consumer takes only what it uses.

Reusability is the direct benefit. A small, focused interface is easy to implement in unrelated classes. A large interface ties those classes to behavior they do not need.

D: Dependency Inversion Principle (DIP)

Also from Robert C. Martin. The principle states that high-level classes should not depend directly on low-level classes. Both should depend on abstractions. The details (low-level implementations) depend on the abstractions, not the reverse.

An uncoupled design does little on its own. A tightly coupled design is expensive to maintain: changing one class forces changes in every class that depends on it. Abstractions break that chain.

Patterns such as dependency injection and the service locator apply DIP in practice. Instead of a class instantiating its collaborators directly, those collaborators are injected through a constructor or interface. The class declares what it needs; the caller decides which implementation to provide.

---

For help applying SOLID in your assignments, visit our Computer Science Homework Help page. You can also read the companion post on Software Design Patterns: How, Where and Why to Use and the overview of Performance Metrics in Software Architecture for the broader context around software quality.