How Many Principles Are There in Design Patterns

Tags:
Categories:

The earliest summarized design patterns consisted of only 5 principles, known as SOLID:

  • Single Responsibility Principle (SRP): A class should have only one reason to change, meaning a class should have only one responsibility.
  • Open/Closed Principle (OCP): Software entities (classes, modules, functions, etc.) should be open for extension but closed for modification. Changes should be implemented through extension rather than modifying existing code.
  • Liskov Substitution Principle (LSP): Subtypes must be substitutable for their base types, meaning derived classes must be able to replace their base classes without affecting the correctness of the program.
  • Interface Segregation Principle (ISP): Clients should not be forced to depend on interfaces they do not use. Large interfaces should be split into smaller, more specific ones so that clients only need to know about the methods they actually use.
  • Dependency Inversion Principle (DIP): High-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend on concrete implementation details; concrete implementations should depend on abstractions.

Later, two additional principles were added. These later additions are more specific and more instructive. From the explanations of the principles, we can see that SOLID describes what should be done, while the later principles describe what is preferred/best to do.

  • Composition/Aggregation Reuse Principle (CARP): Prefer using object composition and aggregation over inheritance for code reuse.
  • Law of Demeter (LoD): An object should have as little knowledge as possible about other objects, meaning an object should know as little as possible about the internal structure and implementation details of other objects.

In addition to the commonly mentioned design principles above, there are other design principles that, while not as widely known, also provide important guidance for software design and architecture. These later proposed rules feel somewhat redundant; at least I believe they are not counter-intuitive and do not require deep thinking.

  • Principle of Least Knowledge (PoLK): Also known as an extension of the Law of Demeter, it advocates that an object should know as little as possible about other objects. This principle dates back to the “Principle of Least Communication” proposed by Patricia Lago and Koos Visser in 1987.
  • Stable Dependencies Principle (SDP): This principle states that software design should ensure that stable components do not depend on unstable components—i.e., components with higher stability should depend less on components with lower stability. The idea behind this principle originates from in-depth research into the relationships between components in software systems.
  • Stable Abstraction Principle (SAP): Complementing the Stable Dependencies Principle, this principle guides matching abstraction with stability—i.e., stable components should be abstract, while unstable components should be concrete. This principle helps ensure the stability and flexibility of software systems.