Introduction to Design Principles
Design principles are some experience summaries that guide our code design. The knowledge of design principles has a very big feature, that is, these principles sound more abstract, the definitions and descriptions are relatively vague, and different people will have different interpretations. Therefore, if you simply memorize the definition, it is of little significance to the improvement of programming and design ability. For each design principle, we need to grasp its original design intention, which programming problems can be solved, and which application scenarios. It mainly includes six basic principles;
1. Single responsibility principle
English full name Single Responsibility Principle, abbreviated as SRP
Introduction:
A class or module is only responsible for completing one responsibility (or function)
achieve:
A class is only responsible for completing a responsibility or function. Don't design large and comprehensive classes, but design classes with small granularity and single function. The single responsibility principle is to achieve high cohesion and low coupling of the code, and to improve the reusability, readability and maintainability of the code.
Determine whether the responsibility is single:
There are too many lines of code, functions or attributes in the
class ; too many other classes that the class depends on, or too many other classes that depend on the class; too many
private methods; it
is difficult to give the class a suitable name; a
large number of methods in the class They are all certain attributes in the centralized operation class.
Second, the principle of opening and closing
Full English name: Open Closed Principle Abbreviation: OCP
Introduction:
The simple understanding is, "open to extension, closed to modification"; a further explanation is that adding a new function should be to extend the code (new modules, classes, methods, etc.) based on the existing code, rather than modify the existing code. There is code (modify modules, classes, methods, etc.).
achieve:
Common implementation methods are: polymorphism, dependency injection, programming based on interfaces rather than implementation, and most design patterns (for example, decoration, strategy, template, chain of responsibility, state, etc.).
Precautions:
1. The principle of opening and closing does not mean that modification is completely eliminated, but to complete the development of new functions at the least cost of modifying the code. And in some cases, the scalability of the code is improved, but the readability is reduced; in many cases, we need to make a trade-off between scalability and readability.
2. The same code change may be regarded as "modification" under coarse code granularity, and may be regarded as "extension" under fine code granularity.
Summary: Many design principles, design patterns, and design ideas regard improving the scalability of the code as the ultimate goal; taking the opening and closing principle as the guiding principle, you can imagine how important the opening and closing principle is;
Third, the principle of Richter substitution
English name: Liskov Substitution Principle Abbreviation: LSP
Introduction:
The object of subtype/derived class can replace any place where the object of base/parent class appears in the program, and the logical behavior of the original program is unchanged and correct. destroyed. To understand the principle of Li substitution, the core thing is to understand the words "design by contract".
The difference between Richter substitution and polymorphism:
Polymorphism is a major feature of object-oriented programming and a syntax of object-oriented programming languages. It is an idea of code implementation. And Li substitution is a design principle used to guide the design of subclasses in the inheritance relationship. The design of subclasses should ensure that when replacing the parent class, it does not change the logic of the original program and does not destroy the correctness of the original program. Sex.
Determine whether it violates the Richter substitution principle:
1. To determine whether the design and implementation of the subclass violates the principle of substitution of Li style, there is another trick, which is to use the unit test of the parent class to verify the code of the subclass.
2. The parent class defines the "convention" (or protocol) of the function. The subclass can change the internal implementation logic of the function, but cannot change the original "convention" of the function. The agreement here includes: the function to be implemented in the function declaration; the agreement on input, output, and exception; and even any special instructions listed in the comments.
Fourth, the principle of interface isolation
English name: Interface Segregation Principle Abbreviation: ISP
Introduction
The client should not be forced to rely on interfaces it does not need. The "client" can be understood as the caller or user of the interface.
Explanation
To understand the principle of interface isolation, the key is to understand the "interface"; there are two types of interface interpretation, 1. If the "interface" is understood as a single API interface or function, and some callers only need part of the function, then we need to The function is split into multiple fine-grained functions, so that the caller only depends on the fine-grained function it needs. 2. If "interface" is understood as an interface in OOP, it can also be understood as an interface syntax in an object-oriented programming language. The design of the interface should be as simple as possible, and the implementation class and caller of the interface should not be dependent on unnecessary interface functions.
The difference between interface isolation and single responsibility
The single responsibility principle is aimed at the design of modules, classes, and interfaces. Compared with the single responsibility principle, the interface isolation principle focuses more on the design of the interface on the one hand, and on the other hand, its thinking angle is different. The principle of interface isolation provides a standard for judging whether the responsibility of an interface is single: indirectly through how the caller uses the interface. If the caller only uses part of the interface or part of the function of the interface, then the design of the interface is not single enough.
Five, rely on inversion
Full English name: Dependency Inversion Principle Abbreviation: DIP Dependency Inversion Principle, also known as Dependency Inversion Principle;
Introduction
High-level modules should not depend on low-level modules. High-level modules and low-level modules should rely on each other through abstraction. In addition, abstraction should not depend on specific implementation details, and specific implementation details depend on abstraction.
Sixth, Dimit's Law
Full English name: Law of Demeter, abbreviation LOD
Introduction
Between classes that should not have direct dependencies, don't have dependencies; between classes that have dependencies, try to only rely on necessary interfaces. Dimit's law is to reduce the coupling between classes, so that the more independent the better. Each class should know less about the other parts of the system. Once a change occurs, there are fewer classes that need to understand the change.
application
Code to achieve high cohesion and low coupling