When we are designing software, we must first fully investigate and collect the needs of users. What the teacher said today inspired me a lot: Change is forever unchanged. Compared with our program design, users' needs It is always changing, so how can we meet the various needs of customers? As we all know, when our program meets the six principles of design patterns, the program will be more flexible. The following is my understanding of the six principles:
Single Responsibility Principle: Single Responsibility Principle
Definition: A class is only responsible for one responsibility
As far as a class is concerned, there is only one reason for its change. The biggest problem I encounter is the definition of responsibilities, what are the responsibilities of the class, and how to divide the responsibilities of the class, which need to be defined by personal experience.
Purpose: Reduce class complexity, improve readability, and improve maintainability.
Liskov Substitution Principle: Liskov Substitution Principle
Definition: The subclass inherits the parent class and can run independently
Wherever the base class appears, the subclass must appear. LSP is the cornerstone of inheritance and reuse. Only when the derived class can replace the base class and the function of the software unit is not affected, the base class can really be reused, and the derived class can also add behavior on the basis of the base class. .
Example: Ball, originally a sporting goods, its derivative classes include football, basketball, etc., if the derivative class replaces the original method of the base class, such as changing sporting goods to food supplies (then the function of the software unit will be affected) ), does not conform to the principle of historical substitution.
Purpose: Specification of concrete steps to achieve abstraction.
Dependence Inversion Principle: Dependence Inversion Principle
Definition: High-level modules should not depend on low-level modules, both should depend on abstraction. Abstraction should not depend on details, and details should depend on abstraction
The principle is for interface programming, not for implementation programming. Refer to an object. If the object has a bottom-level type, directly refer to the bottom-level type.
Example: Take a computer system as an example. Regardless of whether the motherboard, CPU, memory, or hardware are designed for interfaces, if the design is for implementation, the memory must correspond to a motherboard for a certain brand, so if you need to change the memory, you must get the motherboard. Replacement does not conform to the design principles.
Purpose: to reduce the degree of coupling between modules.
Interface Segregation Principles: InterfaceSegregation Principles
Definition: the dependence of one class on another class should be established on the smallest interface
Establish a dedicated interface for each class, instead of trying to build a huge interface for all classes that rely on it to call, the client should not rely on the interface it does not need, each interface should be a role.
Example: Login and registration belong to two interfaces of the user module, which is better than writing one interface.
Purpose: to improve the flexibility of program design.
Note: The interface should be as small as possible, but limited. If the interface is too small, the number of interfaces will be too large and the design will be complicated, so the interface should be moderate.
Demeter Principle: Law of Demeter
Definition: An entity should interact with other entities as little as possible
The Dimit principle is also called the "least-know principle". An object should know as little as possible about other objects (only talk to your direct friends, not to "strangers").
For example: the more public attributes or methods a public has, the greater the area involved in the modification, and the greater the risk caused by the modification.
Purpose: Reduce the coupling between classes and reduce the dependence on other classes.
Open Close Principle: Open Close Principle
Definition: open to expansion, closed to modification