Master SOLID and Beyond: Key Design Principles for Stable Software

Single Responsibility Principle (SRP)

Original: There should never be more than one reason for a class to change. Translation: A class should have only one reason to change. Explanation: Each class should have a single responsibility, like team members working independently without affecting each other. Application: If a class has multiple responsibilities, split it into separate classes to keep responsibilities clear.

Open/Closed Principle (OCP)

Original: Software entities like classes, modules and functions should be open for extension but closed for modifications. Translation: Software components should be extensible without being modified. Explanation: You can add new behavior by extending a class, but you should avoid changing existing code. Application: Use inheritance or composition to extend functionality instead of directly modifying existing classes, unless you are certain the change won’t affect the overall architecture.

Liskov Substitution Principle (LSP)

Original: Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it. Translation: Code that works with a base class should also work with any subclass without modification. Explanation: Subclasses can replace base classes, but not vice‑versa; substituting a subclass should never cause runtime errors. Application: When inheriting, override all relevant base‑class methods, especially protected ones, and avoid exposing unnecessary public methods in the subclass.

Least Knowledge Principle (LKP)

Original: Only talk to your immediate friends. Translation: Interact only with directly related objects. Explanation: Reduce coupling between classes while increasing cohesion. Application: Limit a class’s dependencies on other classes to keep the system understandable and maintainable.

Interface Segregation Principle (ISP)

Original: The dependency of one class to another one should depend on the smallest possible interface. Translation: Depend on the most specific interface needed. Explanation: Do not expose unnecessary methods; keep interfaces practical and focused. Application: If an interface isn’t required, remove it; providing an interface creates future maintenance obligations.

Dependency Inversion Principle (DIP)

Original: High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions. Translation: High‑level components should rely on abstractions, not concrete implementations. Explanation: Program to interfaces rather than implementations to achieve a reverse‑dependency relationship. Application: Use interfaces wherever possible; you don’t need an interface for every class, only when it adds value.

The first letters of these six principles form the acronym SOLID, representing a set of guidelines for creating stable software architectures. While useful, they are recommendations and should be applied flexibly.

Additional Design Principles

Composition/Aggregation Reuse Principle (CARP)

Prefer composition over inheritance when extending class functionality; this principle appears in many design patterns such as Proxy, Decorator, and Adapter.

Acyclic Dependencies Principle (ADP)

Avoid circular dependencies among modules; introduce mediators or other patterns to break cycles.

Common Closure Principle (CCP)

Place classes that change together in the same package, extending the Open/Closed principle.

Common Reuse Principle (CRP)

If a client reuses one class in a package, it should reuse the whole package; keep packages small.

Hollywood Principle (HP)

“Don’t call us, we’ll call you.” In software, this maps to Inversion of Control / Dependency Injection, where a container creates and manages objects instead of the code doing it directly.

Other Design Principles

Don’t Repeat Yourself (DRY)

Avoid duplicated code; encapsulate reusable logic.

Keep It Simple and Stupid (KISS)

Keep systems simple, interfaces clean, and functionality straightforward.

High Cohesion and Low Coupling (HCLC)

Modules should be internally cohesive and loosely coupled to each other.

Convention over Configuration (COC)

Prefer sensible defaults to extensive configuration to improve development efficiency.

Command Query Separation (CQS)

Separate methods that change state (commands) from those that return data (queries).

Separation of Concerns (SOC)

Divide complex problems into independent concerns and address them individually.

Design by Contract (DBC)

Modules interact based on contracts (interfaces/abstractions) rather than concrete implementations.

You Aren’t Gonna Need It (YAGNI)

Don’t over‑engineer; build simple systems that can still be extended when necessary.

Source: CSDN Blog