1. Single Responsibility Principle
Each class should focus on one thing.
2. Liskov Substitution Principle
Where a superclass exists, subclasses are replaceable.
3. Dependence Inversion Principle
The implementation depends on abstraction as much as possible, not on concrete implementation.
4. Interface Segregation Principle
Clients should be provided with as small individual interfaces as possible, rather than a large overall interface.
5. Law of Demeter
Also known as the principle of least knowledge, a software entity should interact with other entities as little as possible.
6. Open Close Principle
Open for extension, closed for modification.
7. Composite/Aggregate Reuse Principle CARP
Try to use synthesis/aggregation to achieve multiplexing, and try to use inheritance as little as possible. Principle: One class has objects of another class.
Rules
Single Responsibility Principle
because:
It can reduce the complexity of the class. A class is only responsible for one responsibility, and its logic must be much simpler than responsible for multiple responsibilities; improve the readability of the class and improve the maintainability of the system; the risk caused by changes is reduced, and changes are Inevitably, if the single responsibility principle is followed well, when one function is modified, the impact on other functions can be significantly reduced. It should be noted that the single responsibility principle is not only unique to the idea of object-oriented programming, as long as it is a modular program design, the single responsibility principle applies.
so:
From the overall point of view, classes such as Paint and Canvas in Android follow the single responsibility principle, and Paint and Canvas perform their own duties.
Liskov Substitution Principle
because:
The Liskov Substitution Principle tells us that when a base class object is replaced by its subclass object in software, the program will not generate any errors and exceptions, and vice versa, if a software entity uses a subclass object , then it is not necessarily able to use the base class object. The Liskov substitution principle is one of the important ways to implement the open-closed principle. Since subclass objects can be used wherever the base class object is used, try to use the base class type to define the object in the program, and then determine it at runtime. Its subclass type, replace the superclass object with the subclass object.
so:
When using the Liskov substitution principle, it is important to note that all methods of the subclass must be declared in the superclass, or the subclass must implement all the methods declared in the superclass. Try to design the parent class as an abstract class or interface, let the child class inherit the parent class or implement the parent interface, and implement the methods declared in the parent class. At runtime, the child class instance replaces the parent class instance, and we can easily expand the system function without modifying the code of the original subclass, adding a new function can be achieved by adding a new subclass.
Looking at the big picture, Java's polymorphism belongs to this principle.
Dependence Inversion Principle
because:
The concrete depends on the abstraction, and the upper layer depends on the lower layer. Suppose B is a lower module than A, but B needs to use the functions of A. At this time, B should not directly use the specific classes in A; instead, B should define an abstract interface, and A should implement this abstract interface, B only uses this abstract interface; in this way, the purpose of dependency inversion is achieved, and B also relieves its dependence on A, and in turn, A depends on the abstract interface defined by B. It is difficult to avoid relying on the lower-level module through the upper-level module. If B also directly depends on the implementation of A, it may cause a circular dependency.
so:
Adopting the dependency inversion principle can reduce the coupling between classes, improve the stability of the system, reduce the risks caused by parallel development, and improve the readability and maintainability of the code.
Looking at the big picture, Java's polymorphism belongs to this principle.
Interface Segregation Principle
because:
Provide as small individual interfaces as possible rather than large total interfaces. Exposing behavior lets later implementing classes know as little as possible. For example, the class ProgramMonkey depends on the class CodeC through the interface CodeInterface, and the class ProgramMaster depends on the class CodeAndroid through the interface CodeInterface. If the interface CodeInterface is not the smallest interface for the class ProgramMonkey and the class CodeC, the class CodeC and the class CodeAndroid must implement methods they do not need. Split the bloated interface CodeInterface into several independent interfaces, and the class ProgramMonkey and the class ProgramMaster establish dependencies with the interfaces they need respectively. That is, the principle of interface isolation is adopted.
so:
Establish a single interface, do not establish a huge interface, try to refine the interface, and minimize the methods in the interface. That is, to create a dedicated interface for each class, instead of trying to create a huge interface for all classes that depend on it to call. Relying on several dedicated interfaces is more flexible than relying on one comprehensive interface. Interfaces are the conventions set externally during design. By defining multiple interfaces in a decentralized manner, the proliferation of external changes can be prevented, and the flexibility and maintainability of the system can be improved.
From the overall point of view, the Java interface can realize multiple inheritance, which is the basic guarantee of the interface isolation principle.
Law Of Demeter
because:
The closer the relationship between classes is, the greater the degree of coupling. Only by reducing the coupling between classes as much as possible can it conform to the design pattern; for the dependent classes, no matter how complex the logic is, try to encapsulate them as much as possible. Inside the class; each object will have a coupling relationship with other objects. We call the classes that appear in member variables, method parameters, and method return values direct coupling dependencies, while classes that appear in local variables are not direct coupling dependencies. , that is to say, classes that are not directly coupled and dependent are best not to appear inside the class as a local variable.
so:
The less an object knows about another object, the better, that is, a software entity should interact with other entities as little as possible, and as few other classes as can be used in one class, especially the dependencies of local variables. Classes can be omitted as much as possible. At the same time, if the two classes do not have to communicate directly with each other, then the two classes should not interact directly. If one of the classes needs to call a method of the other class, the call can be forwarded through a third party.
From the overall point of view, the interactive communication between multiple Fragments and dependent Activities in Android App development abides by this rule.
Open Close Principle
because:
The principle of openness and closure is mainly reflected in the openness of extension and the closure of modification, which means that when there are new requirements or changes, the existing code can be extended to adapt to the new situation. Software requirements are always changing, and no software in the world is constant. Therefore, for software designers, it is necessary to realize flexible system expansion without modifying the original system.
so:
It can be refactored through Template Method mode and Strategy mode to realize the design idea of closed to modification and open to extension.
Encapsulation of changes is an important means to realize the principle of open and closed. For the state that changes frequently, it is generally encapsulated as an abstraction, refusing to abuse the abstraction, and only abstracting the part that changes frequently.
Composite/Aggregate Reuse Principle CARP
because:
In fact, the entire design pattern is about how to combine/aggregate between classes. In a new object, some existing objects are used through association relationships (including combination relationships and aggregation relationships) to make them part of the new object, and the new object can reuse its existing functions by delegating the methods of calling the existing objects. Purpose. That is, try to use the composition and reuse of classes as much as possible, and try not to use inheritance.
If for reuse, two unrelated classes are linked together by inheritance, which violates the Liskov substitution principle. Inheritance and reuse destroys data encapsulation, and exposes all the implementation details of the base class to the derived class. The internal details of the base class are often transparent to the derived class, and white-box reuse; although simple, it is not safe and cannot be used in the program. It can be changed randomly during the running process; the implementation of the base class has changed, and the implementation of the derived class has to be changed; the derived class inherited from the base class is static and cannot be changed at runtime, so it is not flexible enough sex.
so:
The principle of combination/aggregation reuse can make the system more flexible, the coupling between classes is reduced, and the change of one class has relatively little impact on other classes, so it is generally preferred to use combination/aggregation to achieve reuse; Consider inheritance. When using inheritance, you need to strictly follow the Liskov substitution principle. Effective use of inheritance will help understand the problem and reduce complexity, while abuse of inheritance will increase the difficulty of system construction and maintenance and the complexity of the system. , so inheritance reuse needs to be used carefully.
Summary: The seven design principles need to be understood in combination with code;