Understanding the Six Object‑Oriented Design Principles (SOLID)

The article introduces the six fundamental object‑oriented design principles (often abbreviated as SOLID) that are essential for mastering design patterns and writing maintainable code.

Single Responsibility Principle (SRP)

The SRP states that a class should have only one reason to change, meaning it should focus on a single responsibility. When a class handles multiple unrelated methods, a change in one may unintentionally break the other.

Benefits of SRP include reduced class complexity, improved readability and maintainability, and minimized impact when changes occur.

It lowers class complexity, enhances readability and maintainability, and confines the effect of changes to the class itself.

Open/Closed Principle (OCP)

OCP asserts that software entities (classes, modules, functions, etc.) should be open for extension but closed for modification. When requirements evolve, developers should extend existing code rather than modify it, reducing the risk of introducing new bugs.

One way to achieve OCP is to use abstractions for the framework and concrete implementations for details, allowing new behavior via subclassing without altering existing code.

Liskov Substitution Principle (LSP)

LSP requires that objects of a superclass be replaceable with objects of a subclass without affecting program correctness.

All places that use a base type must be able to transparently use objects of any derived type.

In practice, subclasses may implement abstract methods but must not override concrete ones, may add their own methods, must accept broader input parameters when overriding, and must return more specific types when implementing abstract methods.

Dependency Inversion Principle (DIP)

DIP promotes decoupling by ensuring high‑level modules do not depend on low‑level module implementations; both should depend on abstractions.

High‑level modules should depend on abstractions, not on details; abstractions should not depend on details, and details should depend on abstractions.

In Java, abstractions are interfaces or abstract classes, while concrete implementations are the details. The following example shows a tightly coupled design:

public class Hammer {
    public String function() {
        return "用锤子修理东西";
    }
}

public class Worker {
    public void fix(Hammer hammer) {
        System.out.println("工人" + hammer.function());
    }
    public static void main(String[] args) {
        new Worker().fix(new Hammer());
    }
}

To follow DIP, we introduce an interface Tools and let both Hammer and Screwdriver implement it, allowing Worker to depend only on the abstraction:

public interface Tools {
    public String function();
}

public class Worker {
    public void fix(Tools tool) {
        System.out.println("工人" + tool.function());
    }
    public static void main(String[] args) {
        new Worker().fix(new Hammer());
        new Worker().fix(new Screwdriver());
    }
}

public class Hammer implements Tools {
    public String function() {
        return "用锤子修理东西";
    }
}

public class Screwdriver implements Tools {
    @Override
    public String function() {
        return "用螺丝刀修理东西";
    }
}

This interface‑based approach greatly improves extensibility and reduces coupling.

Interface Segregation Principle (ISP)

ISP states that clients should not be forced to depend on interfaces they do not use; interfaces should be fine‑grained so that classes only implement the methods they actually need.

By splitting large interfaces into smaller, role‑specific ones, we avoid unnecessary method implementations and keep designs clean.

Law of Demeter (LOD)

LOD, also known as the principle of least knowledge, advises that a unit should only talk to its immediate friends and not to strangers.

An object should have minimal knowledge of other objects.

In practice, this means limiting dependencies to direct collaborators and avoiding deep object navigation, which reduces coupling and improves maintainability.

Conclusion

The six SOLID principles help developers handle changing requirements with minimal code modifications and impact. While they are guidelines rather than strict rules, applying them wisely—balancing abstraction with simplicity—leads to more robust, extensible software.