Seven Principles of Java Design Patterns

Single responsibility principle

A class should only be responsible for one responsibility, in the case of simple business logic, one method can also be responsible for one responsibility

advantage

Reduce the complexity of the
class ; improve the readability and maintainability of the class ;
reduce the risk caused by changing the class

Precautions

In the case of very simple business logic, the number of classes will increase; therefore, the single responsibility principle can be violated at the code level.
Only the number of methods in the class is small enough to maintain the single responsibility principle at the method level

---

Interface Segregation Principle

A specific class should not rely on interfaces it does not need, that is, the dependence of one class on another class should be based on the smallest interface.
For example, class A implements interface I, class B implements interface I, and class C implements interface I; as shown in Figure
B Only m1 m2 m3 methods are needed, and class C only needs m4 m5 methods, but it is forced to implement all the methods of the interface.

Split the I interface into multiple small interfaces.
I1 interface declaration m1 m2 m3 method, I2 interface declaration m3 m4 method
A type implements I1 interface I2 interface; B type implements I1 interface; C type implements I2 interface;
this avoids subclasses Force the implementation of unnecessary interface methods, reduce method declarations, improve the readability and maintainability of the class;
fully utilize the multiple implementations of Java

---

Dependency inversion (inversion) principle (Interface Segregation Principle)

High-level modules should not rely on low-level modules, both should rely on their abstraction;
abstraction should not depend on details, details should depend on abstraction;
the central idea of ​​dependency inversion (inversion) is interface-oriented programming;
relative to the variability of details, abstract things It is much more stable;
the architecture based on abstraction is much more stable than the architecture based on details;
in java, abstraction refers to interfaces or abstract classes, and details are specific implementation classes;

use:

Precautions:

Low-level modules should have abstract classes or interfaces, or both, to ensure better program stability.
Variable declaration types should be abstract classes or interfaces as much as possible, so that there is a buffer layer between our variable references and actual objects. Facilitate program expansion and optimization of
inheritance to follow the Richter substitution principle

---

Liskov Substitution Principle

Any method that can appear in the base class should also appear
in the subclass when it inherits from the parent class. The structural methods that have been defined in the parent class should not be overwritten;

As shown in the figure above; there is an add() method in the parent class (Base); and the business logic has been implemented; but the sub-class (Sub) rewrites it;
making the original business logic of the parent class change;

Precautions:

While inheritance brings convenience to the program, it also brings disadvantages; inheritance can be intrusive to the program. For
example, a class is inherited by other classes. When this class needs to be modified, all subclasses must be considered. ,
Will there be malfunctions due to the modification of the parent class;
then inherit the parent class, do not rewrite the algorithm skeleton defined by the parent class;

---

Open Closed Principle

Open for extension and closed for modification; when the program needs to be extended, do not modify the original code, but extend the original code;
follow other principles in programming, and the purpose of using design patterns is to follow the principle of opening and closing.

As shown in the figure below; now we need to do a function of drawing graphics, including rectangles and circles;
from this, we can define a base class and declare that the abstract method is implemented by the subclass;

Next, you need to add another triangle drawing class; therefore, you only need to define a triangle class (Triangle) to inherit the base class (Drawing) of drawing graphics, and then implement the abstract method; there
is no need to change the original code at all , You can expand a function;

Precautions:

When using, the base class (Drawing) should be used as the variable type; Dependency inversion (inversion) principle (interface-oriented or abstract class programming)

---

Demeter Principle (Demeter Principle) Least Know Principle

An object should keep the least understanding of other objects;
the closer the relationship between the class and the class, the greater the degree of coupling;
that is, the less a class knows about the classes it depends on, the better. In other words, no matter how complicated the dependent class is, try to encapsulate the logic inside the class. Except for the public methods provided, no information is disclosed

That is, class A refers to class B. The business logic methods defined in class B are only used for this class. The piblic modifier should not be used. The public modifier in this class should be used to call other modifiers in this class. Methods.

---

Synthetic reuse principle

The principle is to use synthesis/aggregation as much as possible instead of inheritance;
if you only use some methods of a certain class, you should not inherit this class

For the following class, other classes just want to use some of these methods; if inherited, obviously the degree of coupling is very large;

you can use the synthesis/aggregation method as follows:

The above is just a simple code demonstration, the actual situation depends on the project.

---

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.
• Design for loose coupling between interactive objects