Common Responsibility Assignment Software Patterns, Design Principles, Design Patterns

Speaking of software design is actually a high and profound thing. It is the realm of a master to be able to climb high and look at the small mountains and look down at the world. I am waiting on the way. . .
A complex design is made up of concrete classes and objects. Before there are classes, there is a relationship between classes.
GRASP is how to design the principles that guide us to design good classes.

1.Information Expert (Information Expert)
The information expert mode is the most basic principle of object-oriented design. It is the principle that we use the most and should be integrated with our thoughts. That is to say, when we design objects (classes), if a class has all the information needed to complete a certain responsibility, then this responsibility should be assigned to this class to achieve. At this point, the class is the information specialist relative to this responsibility.

2.Creator In
practical applications, when any of the following conditions are met, class A should create class B. At this time, A is the creator of
B: a.A is the aggregation of
B.B.A is B. The container
c.A holds the information (data) that initializes B
d.A records the instance of B
e.A frequently uses B
If one class creates another class, then there is a coupling between the two classes, and you can also Says a dependency is created. Dependency or coupling itself is not wrong, but the problem they bring is that there will be a chain reaction in future maintenance, and the necessary coupling cannot be escaped. Dependencies between classes, so how to do it? It is to abide by the basic principles stipulated by the creator mode. If the above conditions are not met, A cannot be used to create B.

3.Low coupling (low coupling)
Low coupling mode means that we want to reduce the connection between classes as much as possible.

Its role is very important:
a. Low coupling reduces the scope for changes in one class to affect other classes.
b. Low coupling makes classes easier to understand because classes become simpler and more cohesive.
The following situations will cause coupling between classes A and B:
aA is an attribute of B,
bA calls a method of B's ​​instance, and
cA's method references B, for example, B is the return value or parameter of A's method.
dA is a subclass of B, or A implements B.
Regarding low coupling, there are some basic principles as follows: a. Don't
Talk to Strangers principle:
It means that between two objects that do not need to communicate, there should be no needless conduct. If the connection is not connected, there may be problems. If it is not connected, it will be a hundred times!
b. If A is already connected to B, if it is inappropriate to assign the responsibility of A to B (violating the information expert model), then assign the responsibility of B to A.
c. The inner classes of two different modules cannot be directly connected, otherwise there will be retribution! Hey!

4.High cohesion (high cohesion)
High cohesion means to assign cohesion responsibilities to classes as much as possible, which can also be said to be functional cohesion responsibilities. That is, functionally closely related responsibilities should be placed in a class and jointly complete limited functions, then it is high internal aggregation. This is more conducive to the understanding and reuse of the class, and also facilitates the maintenance of the class.
High cohesion can also be said to be a kind of isolation. Just think that the human body is composed of many independent cells, and the building is composed of many bricks, steel bars, and concrete. Each part (class) has its own independent responsibilities and characteristics. If a problem occurs, it will not affect other parts, because the highly cohesive objects are isolated.

5. Controller
The responsibility for receiving and processing system events should generally be assigned to a class that represents the entire system. Such a class is usually named "XX handler", "XX coordinator" or "XX session".
Regarding the controller class, there are the following principles:
a. The reception and processing of system events are usually replaced by a high-level class.
b. A subsystem will have many controller classes that handle different transactions.

6.Polymorphism (polymorphism) The polymorphism
here has the same meaning as "polymorphism", one of the three basic characteristics of OO.

7. Pure Fabrication (pure fictitious)
The pure fictitious here is similar to the pure fictitious function we often say. High cohesion and low coupling are the ultimate goals of system design, but cohesion and coupling are always contradictory. High cohesion thinks that this splits up a larger number of classes, but objects need to cooperate to complete tasks, which in turn creates high coupling, and vice versa. How to solve this contradiction? At this time, a pure fictional model is needed, and a pure fictional class is used to coordinate cohesion and coupling, which can solve the above problems to a certain extent.


8. Indirection
"Indirect", as the name implies, means that this matter cannot be done directly, it needs to be detoured. The advantage of taking a detour is that objects that would otherwise be directly connected are isolated from each other, and changes in one will not affect the other. Just like what I said in the previous low-coupling mode, "the inner classes of two different modules cannot be directly connected", but we can indirectly connect two different modules through intermediate classes, so that for these two modules In other words, there is still no coupling/dependency between them.


9.Protected Variations
Find unstable change points in advance and encapsulate them with a unified interface. If changes occur in the future, you can extend new functions through the interface without modifying the original old implementation. This pattern can also be understood as the OCP (Open Closed Principle) principle, which means that a software entity should be closed for extension development and closed for modification. When designing a module, make sure that the module can be extended without modification. The advantage of this is that it provides new responsibilities to the system by extending it to meet new requirements without changing the original function of the system. Regarding the OCP principle, there will be a separate discussion later.


SOLID is an acronym for several important programming principles in object-oriented design and programming (OOD&OOP).

SRP The Single Responsibility Principle
OCP The Open Closed Principle
LSP The Liskov Substitution Principle
ISP The Interface Segregation Principle
DIP The Dependency Inversion Principle

1. The Single Responsibility Principle (SRP) should
      be There is one and only one reason when you need to modify a class. In other words, let a class do only one type of responsibility. When this class needs to take responsibility for other types, it needs to be decomposed. There is a high chance that the class will be modified, so it should focus on a single function. If you put multiple functions in the same class, the functions are associated with each other. If you change one of the functions, it is possible to abort the other function. At this time, a new round of testing is required to avoid possible problems. Time consuming and laborious.

2. Open Closed Principle (OCP)
Software entities should be extensible, not modifiable. That is, it is open for extension and closed for modification. This principle is one of the most abstract and difficult to understand of many object-oriented programming principles.

(1) Extend functionality by adding code, rather than modifying existing code.
(2) If the client module and the service module are designed according to the same interface, the client module can not care about the type of the service module, and the service module can easily extend the service (code).
(3) OCP supports alternate services without modifying client modules.

3. Liskov Substitution Principle (LSP)

When an instance of a subclass should be able to replace an instance of any of its superclasses, there is an is-A relationship between them The

client module should not care how the service module works; the same Between interface modules, substitutions can be made without knowing the code of the service module. That is, where the interface or parent class appears, the class or subclass that implements the interface can be substituted.


4. The Interface Separation Principle (ISP)

cannot force users to rely on interfaces they do not use. In other words, using multiple specialized interfaces is always better than using a single overall interface.
Client modules should not depend on large interfaces, but should be reduced to small interfaces for client modules to use to reduce dependencies. For example, a class in Java implements multiple interfaces, and different interfaces are used by different client modules, instead of providing a large interface to client modules.


5. Dependency Injection or Inversion Principle (DIP)

1. High-level modules should not depend on low-level modules, both should depend on abstractions
2. Abstractions should not depend on details, details should depend on abstractions

The highlight of this design principle is that any class injected by the DI framework is easy to test and maintain with mock objects, because the object creation code is centralized in the framework and the client code is not cluttered. There are many ways to implement dependency inversion, such as bytecode technology used by AOP (Aspect Oriented programming) frameworks such as AspectJ, or proxies used by Spring framework.

(1) High-level modules should not depend on low-level modules;
(2) Both high-level and low-level modules should depend on abstraction;
(3) Abstraction should not depend on concrete implementation;
(4) Concrete implementation should depend on abstraction;
(5) .Abstracts and interfaces separate dependencies between modules.


The design pattern is the solution of the scene and the concrete embodiment of the above principles.
Creation type

1. Factory Method

2. Abstract Factory

3. Builder

4. Prototype

5. Singleton Example)

Structural

6. Adapter Class/Object

7. Bridge

8. Composite

9. Decorator

10. Facade

11. Flyweight

12. Proxy

Behavioral

13. Interpreter

14. Template Method

15. Chain of Responsibility

16. Command

17. Iterator

18. Mediator

19. Memento

20. Observer

21. State

22. Strategy

23. Visitor