Design Pattern arrangement-surface relative Image Design Principles

I. Design Pattern principles:

1,Single responsibility principle:

Specific description: there should be only one reason for a class change, that is, a method should do only one thing as much as possible, that is, to implement only one function as much as possible, and an interface should be responsible for only one class of function description as much as possible, the Design of classes should be changed for only one reason.

Benefits:

Reduce the complexity of classes, implement clear definitions of all responsibilities, improve readability, improve maintainability, and reduce risks caused by changes. It is thought that a change is caused by only one reason, and the change caused by the change is only convenient.

2,Lee's replacement principle:

Description:

All objects that reference the base class must be transparently used. That is, as long as the parent class can appear, the subclass can appear, and replacement with the subclass will not cause any errors or exceptions, however, the user may not need to know whether it is a parent class or a subclass, but in turn cannot. Where a subclass appears, the parent class may not be able to adapt.

Generally, child classes must fully implement the parent class method, but child classes can have their own personality.

Benefits:

The purpose of using the Lee's replacement principle is to enhanceProgramRobust. The version upgrade can also maintain excellent compatibility. Even if the subclass is added, the original subclass can continue to run. In actual applications, each subclass corresponds to different business meanings, using the parent class as a parameter and passing different sub-classes can complete different business logic. Of course, to use the sub-class "personalized" business logic, you must create a sub-class object. However, when designing a class using the Lishi replacement principle, we should try to avoid the sub-class "personalized ".

Note:: When overwriting or implementing the parent class method, the input parameter can be enlarged. Therefore, the preconditions of the method in the subclass must be the same or wider than that of the override method in the superclass.

The output result can be reduced by overwriting or implementing the parent class.

3,Dependency inversion principle:

Specific description: The high-level module should not depend on the underlying module. Both of them should depend on its abstraction. abstraction should not depend on implementation details. Details should depend on abstraction. That is, inter-module dependency occurs through abstraction, there is no direct dependency between implementation classes. Their dependency relationships are generated through interfaces or abstract classes. interfaces or abstract classes do not depend on implementation classes. Implementation classes depend on interfaces or abstract classes.

The object dependency can be passed in the following ways:

A. the constructor passes the dependent object, that is, the dependent object is declared in the class through the constructor.

B. Pass the API as a parameter through function Transfer

C. The interface declares the object dependency, that is, the dependency is generated through the declaration interface.

General implementation:

A. Every class should have an excuse or abstract class and interface as much as possible.

B. The surface type of variables is an excuse or abstract class as much as possible.

C. No class should be derived from a specific implementation class

D. Try not to overwrite the base class Method

E. It is used in combination with the lean replacement principle, that is, the interface is responsible for defining public attributes and methods, and declaring dependencies with other objects. The abstract class is responsible for implementing public constructors, the implementation class can accurately implement the business logic and refine the parent class when appropriate, but avoid subclass "personalization" whenever possible ".

In actual projects, the dependency inversion principle is adopted for large projects, which makes maintenance easy and easy to expand.

4,Interface isolation principle:

Description:

The client should not keep the interface as pure as possible because it does not need the interface. The dependency between classes should be established on the smallest interface, that is, a single interface should be established, make the interface as detailed as possible, and minimize the number of methods in the interface.

General implementation:

A. The interface should be as small as possible, but it should not violate a single responsibility

B. Interfaces must be highly cohesive, which improves the processing capabilities of interfaces, classes, and modules, reduces external interactions, and enables them to perform their respective duties, but cooperate with each other. That is, the public method should be published as few as possible in the interface. The interface is an external commitment. The less the commitment, the more favorable the system development, the less the risk of changes, and the lower the cost.

C. customized services, that is, providing advantageous services for individual entities, specifically, providing only the methods required by visitors.

D. the granularity of interface design is limited. On the premise of maintenance and development, the design granularity is as small as possible to make the system more flexible.

Generally, in actual projects, interfaces and classes are assembled using atomic interfaces or atomic classes as much as possible, so that an interface can only serve a submodule or business logic, and the public method in the interface is compressed by business logic, we often review the interface and try to reduce its granularity. However, if the interface has been coupled or has too many coupling interfaces, we should try to modify them. However, if the risk of changes is too high, then try to use the adapter mode for conversion. However, do not confuse yourself. You need to understand the environment, reject blind access, go deep into the business logic, and design interfaces for the business logic.

5,Dimit rules:

Description:

An object should have a minimum understanding of other objects, or a class should have a minimum understanding of the classes that need to be coupled or called.

General implementation:

Objects are directly coupled with each other for class communication. during design, it is necessary to repeatedly determine whether public methods and attributes can be reduced, and whether they can be changed to other classes such as private, whether the access permissions such as protected can be added with final. If a method is put in this class, that is, there is no relationship between classes, and there is no negative impact on this class, it is placed in this class. Exercise caution when using serializable. The core concept of the dimit rule is inter-class decoupling, weak coupling, and class reuse rate can be improved. However, decoupling means that a secondary or jump class is generated, at the same time, the complexity of the system is improved, and maintenance brings difficulties. Therefore, we need to weigh the Rules repeatedly to make the structure clear and achieve high cohesion and low coupling.

6,Closing principle:

Description:

A software entity, such as classes, modules, and functions, should be developed for extension and disabled for modification.

General implementation:

Try to use extended software entities (modules, abstractions, classes, and methods in projects or software products that are planned according to certain logic) instead of modifying existingCodeTo complete the changes, that is, to reserve or provide scalable interfaces or methods during the design. General changes can be summarized as logical changes, sub-module changes, and view changes.

Benefits of the open/closed principle:

A. Impact on testing: the newly added classes and newly added testing methods only need to ensure the correctness of the newly added classes.

B. improve reusability

C. improve maintainability

How to use:

A. Abstract constraints: the extension is defined through interface or abstract class constraints. Public methods that do not exist in interfaces or abstract classes are not allowed, at the same time, the interface or abstract class should be used as much as possible for the parameter type and reference type, instead of the implementation class. The stability of the abstraction layer should be ensured during design. Once determined, the parameter type and reference type cannot be changed.

B. Metadata control module behavior, that is, data describing the environment and data, or configuration parameters. parameters can be obtained from files or databases.

C. Develop Project Charter: establish relevant regulations between teams so that members can comply with the Rules as much as possible.

D. encapsulation changes: encapsulate the same changes into an interface or abstract class, and encapsulate different changes into different interfaces or abstract classes, there shouldn't be two different changes in the abstract class behind the same interface.