For classes, a class should only be responsible for one responsibility (not a class has only one method, there can be multiple methods, and these methods work together to complete one responsibility).
If a class assumes too many responsibilities, it is equivalent to coupling these responsibilities together. A change in one responsibility may weaken or inhibit the ability of this class to perform other responsibilities; this coupling will lead to fragile design. When changes occur, the design Will suffer unexpected damage.
Much of what software design really needs to do is to discover responsibilities and separate those responsibilities from each other.
If you can think of more than one motivation to change a class, then this class has more than one responsibility.
Under normal circumstances, we should abide by the single responsibility principle. Only when the logic is simple enough, can the single responsibility principle be violated at the code level; when the number of methods in the class is small enough, the single responsibility principle can be maintained at the method level.
The role of the single responsibility principle:
Reduce the complexity of the class, a class is only responsible for one responsibility.
Improve the readability and maintainability of the class.
Reduce the risks caused by changes.
2. Richter substitution principle
statement of problem:
Inheritance contains such a meaning: all the methods that have been implemented in the parent class are actually setting specifications and contracts. Although it does not force all subclasses to comply with these contracts, if the subclass has implemented these methods Arbitrary modification of the method will cause damage to the entire inheritance system.
While inheritance brings convenience to programming, it also brings disadvantages. For example, the use of inheritance will bring invasiveness to the program, reduce the portability of the program, and increase the coupling between objects. If a class is inherited by other classes, when this class needs to be modified, all subclasses must be considered , And after the parent class is modified, all functions related to the child class may malfunction.
In programming, how to use inheritance correctly? => This puts forward the principle of Liskov substitution
The Liskov Substitution Principle was proposed in 1988 by Ms. Barbara Liskov of the Massachusetts Institute of Technology.
The vernacular translation of its content is that if a software entity uses a parent class, then it must be applicable to its subclasses, and it cannot detect the difference between the parent class object and the subclass object; in other words, in software, The parent class is replaced with its subclasses, and the behavior of the program remains unchanged.
Simply put, subtypes must be able to replace their supertypes.
Only when the subclass can replace the parent class and the function of the software unit is not affected, the parent class can be reused, and the subclass can also add new behaviors on the basis of the parent class.
Because the subtypes are replaceable, the modules that use the parent type can be extended without modification.
Points to note about the Richter substitution principle:
When using inheritance, follow the Richter substitution principle and try not to override the method of the parent class in the subclass.
The Richter substitution principle tells us that inheritance actually enhances the coupling of two classes. Under appropriate circumstances, the original parent class and subclass can inherit a more popular base class, and the original inheritance relationship is removed. Use dependence, aggregation, combination and other relations instead.
3. Rely on the principle of inversion
High-level modules should not rely on low-level modules, both should rely on abstraction. In other words, we can rely on interfaces, we can rely on abstract classes, but we should not rely on a specific subclass.
Abstraction should not depend on details, and details should depend on abstraction. In other words, we must program the interface, not the implementation.
The principle of dependency inversion is based on the design concept: Compared with the variability of details, abstract things are much more stable. Architecture based on abstraction is much more stable than architecture based on details. In Java, abstraction refers to interfaces or abstract classes, and details are specific implementation classes.
The purpose of using interfaces or abstract classes is to formulate specifications without involving any specific operations, and to delegate the task of displaying details to their implementation classes.
Details of using the dependency inversion principle:
The underlying module should have abstract classes or interfaces as much as possible, or both, and the program stability is good.
The declaration type of the variable should be an abstract class or interface as much as possible, so that there is a buffer layer between our variable reference and the actual object, which is conducive to program expansion and optimization.
Follow the Richter substitution principle when inheriting.
4. Interface isolation principle
The client should not rely on interfaces it does not need, that is, the dependence of one class on another should be built on the smallest interface.
Graphic explanation:
Class A depends on Class B through Interface1, and Class C depends on Class D through Interface1. If Interface1 is not the smallest interface for Class A and Class C, then Class B and Class D must implement methods they do not need.
According to the isolation principle, it should be handled as follows: Split interface Interface1 into several independent interfaces, and class A and class C respectively establish dependencies with the interfaces they need. That is, the principle of interface isolation is adopted, as follows:
5. Principle of opening and closing
The Open Closed Principle is the most basic and important design principle in programming.
The principle of opening and closing is that software entities (classes, modules, functions, etc.) should be extensible, but not modifiable.
That is to say, it is open for extension and closed for modification.
Follow other principles in programming, and the purpose of using design patterns is to follow the principle of opening and closing.
No matter how "closed" the module is, there will be some changes that cannot be closed. Since it is impossible to completely close, the designer must make a choice about which changes should be closed for the module he designs. He must first guess the kinds of changes that are most likely to occur, and then construct abstractions to isolate those changes.
In the face of demand, changes to the program are performed by adding new code, rather than changing the existing code.
What we want is to know possible changes soon after development work begins. The longer it takes to identify possible changes, the more difficult it is to create the correct abstraction.
The principle of opening and closing is the core of object-oriented design. Following this principle can bring the huge benefits claimed by object-oriented technology, that is, maintainability, scalability, reusability, and flexibility. Developers should only abstract those parts of the program that show frequent changes; however, it is also not a good idea to deliberately abstract every part of the application. Rejecting immature abstractions is as important as abstraction itself.
6. Dimit's Law
One object should keep a minimum of knowledge of other objects.
The closer the relationship between class and class, the greater the degree of coupling.
Demeter Principle is also called the Least Knowing Principle, that is, the less a class knows about the classes it depends on, the better; if two classes do not need to communicate directly with each other, then the two classes should not directly communicate with each other. effect. If one of the classes needs to call a method of another class, the call can be forwarded through a third party.
Dimit’s rule first emphasizes the premise that in the structural design of the class, each class should minimize the access rights of members, that is to say, a class packs its own private state and does not require fields that other classes know Or do not make it public.
The fundamental idea of Dimit's Law is to emphasize loose coupling between classes.
The weaker the coupling between classes, the more conducive to reuse. A class in weak coupling is modified, and the related classes will not be affected. In other words, the hiding of information promotes the reuse of software.
Dimit's rule has a simpler definition: only communicate with direct friends. What is a direct friend:
Direct friends: Every object will have a coupling relationship with other objects. As long as there is a coupling relationship between two objects, we say that the two objects are friends. There are many ways of coupling, such as dependence, association, combination, and aggregation. Among them, we call the classes that appear in member variables, method parameters, and method return values as direct friends, while classes that appear in local variables are not direct friends. In other words, unfamiliar classes are best not to appear inside the class in the form of local variables.
7. Principles of composite reuse
The principle is to use composition/aggregation as much as possible instead of using inheritance.
For example, if there are two methods in class A, and we want two methods in class A to be used in class B, we have the following methods:
Let class B inherit class A, so that class B can use the methods in class A, but this method should be used as little as possible, because it improves the coupling between classes.
Let the formal parameter type of a method in class B be class A
Let the type of an attribute in class B be class A
8. Summary of core ideas of design principles
Find out where changes may be needed in the application, isolate them, and don't mix them with code that does not require changes.
Programming for the interface, not for the implementation.
Work hard for the design of loose coupling between interactive objects.
