Object-Oriented Design Principles

From: Agile Software Development: Principles, models, and practices: Robert C. Martin, translated by Deng Hui]

Class Design Principles:
(1) SRP, The Single Responsibility Priciple ):
For a class, there should be only one reason for its change.

(2) OCP, The Open-Close Priciple principle ):
Software entities (classes, modules, functions, etc.) should be extensible, but cannot be modified. closures are built on abstraction, we should only abstract the frequently changed parts of the program. Rejecting immature abstraction is just as important as the abstraction itself! The main mechanisms behind OCP are abstraction, polymorphism, and inheritance.

(3) LSP and Liskov replacement principles (The Liskov Substitution Priciple ):
Child types must be able to replace their base types. Violation of LSP often leads to the use of runtime type recognition (RTTI) (using an explicit if statement or if/else chain to determine the type of an object ).

(4) DIP, The Dependency Inversion Priciple ):
The high-level module should not depend on the underlying module, both of which should depend on abstraction; abstraction should not depend on details; details should depend on abstraction. In fact, we violate DIP whenever we use new to create objects; but sometimes such violations are harmless, for example, dependent on specific classes that are stable and unchanged.

(5) ISP, Interface isolation principle (The Interface Segregation Interface ):
Customers should not be forced to rely on methods they do not need. Interfaces belong to customers, not the class hierarchies they belong.
Fat classes lead to abnormal and harmful coupling between their customer programs. When a customer program requires a change to the fat class, it will affect all other customer programs. Therefore, the customer program should only rely on the methods they actually call. This goal can be achieved by decomposing the fat class interface into multiple specific interfaces with the customer program, each client-specific interface only declares the functions called by specific customers or customer groups. Then, the fat class can inherit all the customer-specific interfaces and implement them. This removes the dependency between the customer program and the methods they do not call, so that the customer program does not depend on each other. Separating customers is the splitting interface!

 

Package Design-cohesion principle:
(1) REP, reuse release equivalence principle:
The granularity of reuse is the publishing granularity.

(2) CCP, the principle of joint closure:
All classes in the package should be closed for changes to the same class nature. If a change affects a package, it will affect all classes in the package, without affecting other packages.

(3) CRP, the principle of joint reuse:
All classes in a package should be reused together. If a class in the package is reused, all classes in the package should be reused.

Package Design-coupling principle:
(1) ADP, no-ring dependency principle:
The package dependency graph does not allow loops.

(2) SDP: stable dependency principle:
Dependency in a stable direction.

(3) SAP: stable abstraction principles:
The abstraction level of the package should be consistent with its stability.