Seven basic design principles:
| abbreviations | The English name | Chinese name | Chinese name |
|---|---|---|---|
| SRP | Single Responsibility Principle | Single responsibility principle | Each class should focus on doing one thing |
| OCP | Open Close Principle | The open closed principle | Open for extension, closed for modification |
| LSP | Liskov Substitution Principle | Richter’s substitution principle | The implementation relies on abstraction rather than concrete implementation |
| ISP | Interface Segregation Principle | Interface separation principle | The client should be provided with the smallest possible individual interface, rather than a large total interface |
| DIP | Dependency Inversion Principle | Dependency inversion principle | The implementation relies on abstraction rather than concrete implementation |
| LoD | Law of Demeter (Least Knowledge Principle) | Demeter’s Rule (least Know rule) | Also known as the least knowledge principle, a software entity should interact with as few other entities as possible |
| CARP | Composite/Aggregate Reuse Principle CARP | Synthesis/polymerization reuse principle | Use composition/aggregation as much as possible for reuse and inheritance as little as possible. Principle: One class has an object of another class |
Note that the design principles commonly referred to as SOLID (the initials of the table above, from top to bottom) do not contain Demeter’s law, but only the other five
Principle 1: open and close principle
A software entity such as a class, module, or function should be open for extension and closed for modification
Define the interpretation
- Build the framework with abstractions and extend the details with implementations
- New requirements should not be implemented by modifying existing classes, but rather by implementing preabstracted interfaces (or concrete classes inheriting abstract classes)
advantages
The advantage of practicing the open close principle is that you can extend functionality without changing the original code. The expansibility of the program is increased, and the maintenance cost of the program is reduced.
How to practice
In order to best practice the open close principle, it is important at the beginning of the design to figure out which data (or behaviors) in the scenario are fixed (or hard to change) and which are easily changeable. The latter can be abstracted into interfaces or abstract methods so that different requirements can be addressed in the future by creating concrete implementations.
Principle two: Single responsibility principle
A class is allowed to have only one responsibility, that is, only one reason for the change of that class
Define the interpretation
- Changes in class responsibilities are often the cause of class changes: that is, if a class has more than one responsibility, there will be more than one reason for that class to change, making maintenance of that class difficult
- Often in software development, as the requirements continue to increase, it is possible to add some responsibilities to the original class that do not belong to it, thus violating the single responsibility principle. If we find that the current class has more than one responsibility, we should separate out responsibilities that are not really part of the class
- Not only classes, but also functions (methods) follow the single responsibility principle: a function (method) does only one thing. If you find a function (method) with different tasks, you need to separate out the different tasks in the form of another function (method)
advantages
A clear division of responsibilities between classes and methods not only improves the readability of the code, but also substantially reduces the risk of errors, because clear code leaves bugs nowhere to hide and facilitates bug tracking, which in turn reduces maintenance costs
How to practice
In practice, it’s easy to combine different responsibilities, and developers need to be aware of this
Principle three: dependence inversion principle
- Rely on abstraction, not implementation
- Abstractions should not depend on details, details should depend on abstractions
- High-level modules cannot depend on low-level modules; both should depend on abstractions
Define the interpretation
- Program for interfaces, not implementations
- Try not to derive from concrete classes, but instead implement by inheriting abstract classes or implementing interfaces
- The division of high-level module and low-level module can be divided according to the level of decision-making ability. The business layer is naturally placed in the upper module, and the logical layer and data layer are naturally categorized as the bottom layer
advantages
Through abstraction to build the framework, the establishment of class and class association, in order to reduce the coupling between classes. Moreover, the system built by abstraction is more stable, more expansible and easier to maintain than the system built by concrete implementation
How to practice
In the future, when dealing with the interaction of high and low level modules (classes), we should try our best to remove the dependence of the two by abstract means, which can be implemented through interfaces or abstract classes
Principle 4: Interface separation
Multiple specific client interfaces are better than one universal master interface
Define the interpretation
- A client should not rely on interfaces it does not need to implement
- Instead of creating a large and bloated interface, you should refine the interface as much as possible and use as few methods as possible
Note that the granularity of interfaces should not be too small. If the size is too small, the number of interfaces is too large, which complicates the design
advantages
Avoid the method that the same interface contains different kinds of responsibilities, and the interface responsibility division is more clear, in line with the idea of high cohesion and low coupling
How to practice
Because of the redundancy caused by the design of interface methods, the design does not comply with the principle of interface isolation.
When designing interfaces, and especially when adding methods to existing interfaces, we need to carefully consider whether these methods address the same kind of task: if so, they can be put together; If not, you need to split it
Principle 5: Demeter’s Rule
An object should touch as few objects as possible, that is, only those that really need to be touched
Define the interpretation
Also known as the Least Know Principle, a class should communicate only with classes in its member variables, method inputs, and return parameters, and should not introduce other classes (indirect communication)
advantages
Practice of Demeter’s law can well reduce the coupling between classes, reduce the degree of association between classes, and make the collaboration between classes more direct
How to practice
In the future, when designing the interaction between objects, we should try our best to avoid eliciting intermediate objects (classes of other objects need to be imported) : what objects need to be returned directly, reducing the degree of coupling between classes
Principle 6: Richter’s substitution principle
All references to a base class must be able to use objects of its subclasses transparently, that is, subclass objects can replace their parent class objects without the program executing the same
Define the interpretation
In the inheritance system, a subclass can add its own unique methods and implement the abstract methods of the parent class, but cannot override the non-abstract methods of the parent class, otherwise the inheritance relationship is not a correct inheritance relationship.
advantages
It can check the correctness of inheritance and restrain the overflow of inheritance in use
How to practice
Richter’s substitution principle is a test of inheritance relation: to check whether it really conforms to inheritance relation, so as to avoid the abuse of inheritance. Therefore, before using inheritance, it is necessary to repeatedly consider and confirm whether the inheritance relationship is correct, or whether the current inheritance system can support subsequent requirement changes. If not, it is necessary to timely reconstruct and adopt a better way to design the program
Principle 7: Synthesis/polymerization reuse principle
Use composition/aggregation as much as possible for reuse and inheritance as little as possible. Principle: One class has an object of another class
Define the interpretation
Take some existing objects and make them part of the new object. The new object can reuse its existing functions by delegating methods that call the existing object. That is, use synthetic reuse of classes as much as possible, and avoid inheritance as much as possible
advantages
The combination/aggregation reuse principle can make the system more flexible, the degree of coupling between classes is reduced, and the change of one class has less impact on other classes
How to practice
When using inheritance, we should strictly follow the Leighton substitution principle. The effective use of inheritance will help to understand the problem and reduce the complexity, while the abuse of inheritance will increase the difficulty of system construction and maintenance and the complexity of the system. Therefore, we should carefully use inheritance reuse
The seven basic principles of object-oriented design patterns