Six design principles of design patterns (I)

Six Design Principles

 

• Single Responsibility Principle
• Rys replacement principle
• Dependency inversion principle
• Interface isolation principle
• Dimit Law
• Principle of opening/closing

 

1. Single Responsibility Principle)

Single responsibility, SRP for short. The definition of a single responsibility is: there should be only one reason for class changes. The most difficult part of a single responsibility is responsibility. A responsibility is an interface, but the responsibility is divided by project.For interfaces, we must be single during design, but there is only one reason to change the implementation class.A single role of implementation class will cause a sharp increase in class.

 

2. liskov substitution principle)

LSP for short. In general, as long as the parent class can appear, the Child class will appear, and replacing it with the Child class will not produce any errors or exceptions. The user may not need to know whether it is a parent class or a child class. However, where child classes appear, the parent class may not be able to adapt.

The Lee's replacement principle contains four meanings:

1)Subclass must fully implement the parent class method.When calling other classes in the class, you must use the parent class or excuse. If you cannot use the parent class or excuse, it indicates that it violates the LSP principle.

2)Child classes can have their own personalities.

3)Parameters can be enlarged when override or parent class methods are implemented.The Lee's replacement principle requires a contract, that is, a parent class or an excuse. This design method is also called design by contract (Contract Design), which is similar to the lee's replacement principle. The preconditions of the method in the subclass must be the same or looser than that of the method that is overwritten in the superclass.

4)Output results can be reduced when overwriting or implementing the parent class method.

3 Dependency inversion principle (dependence inversion principle)

Dependency inversion principle, dip for short. It means that the high-level module should not depend on the lower-level module, both of which should depend on its abstraction; abstraction should not depend on details; details should depend on abstraction. A more streamlined definition is"Interface-oriented programming".

There is a dependency between the two classes. As long as the interfaces (or abstract classes) between the two can be developed independently, and unit tests between projects can also be run independently, the TDD (test-driven development, test-driven development) development mode is the most advanced application that relies on the inversion principle.

Abstraction is the constraint on implementation. It is also a contract for dependent persons. Not only constrain yourself, but also constrain the relationship between yourself and the outside. The purpose is to ensure that all details are not in the scope of the contract and that both parties are bound to develop together in accordance with the established contract (abstraction.

Three methods of dependency transmission:

1) The object passed by the constructor. Declare the dependent object through the constructor in the class. According to the dependency injection statement, this method is called constructor injection.

2) the setter method transmits the dependent object. Set the setter method in the abstract to declare the dependency, which is also known as setter dependency injection.

3) interface declaration dependent object, also known as interface injection.

The principle of dependency inversion is essentially to make the implementation of each class or module independent from each other through abstraction (interface or abstract class), so as to achieve loose coupling between modules.We can follow the following rules: each class should have an interface or abstract class, or both; The Declaration type of the variable should be an interface or abstract class; no class should be derived from a specific class; do not overwrite the base class method as much as possible. The following rule can be obtained in combination with the lean replacement principle: the interface is responsible for defining public attributes and methods and declaring dependencies with other objects, abstract classes are responsible for the implementation of the public constructor part, implementing the class to accurately implement the business logic, and refining the parent class as appropriate.

 

4. Interface segregation principle)

The interface isolation principle indicates that the client should rely on the interfaces it needs to provide only the required interfaces, remove unnecessary interfaces, and refine the required interfaces to ensure their purity. The methods in the interface should be as few as possible.

A single responsibility requires a single responsibility for classes and interfaces, and focuses on duties. This is a logical Business Division, and the interface isolation principle requires that the interface methods should be as few as possible.

To ensure the purity of the interface

1)The interface should be as small as possible.When splitting an interface based on the Interface isolation principle, the single responsibility principle must be met first.

2)The interface must be highly cohesive.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 it will be, the lower the risk of changes, and the lower the cost.

3)Custom Service.It provides excellent services for individual entities and only provides the methods required by visitors.

4)The interface design is limited.The granularity of the interface design should be moderate.

 

5 Law of Demeter)

This is also known as the least knowledge principle (LKP ). A class should have the least knowledge of its own coupling or called classes.

The dimit rule requires that you do not publish too many public and non-static public methods to the outside world. You should use private, package-private, protected, and other access permissions.

If a method is put in this class, neither adding inter-class relationships nor negatively affecting the class, it will be placed in this class.

The core of the dimit rule is inter-class decoupling and weak coupling. The Reuse Rate of classes can be improved only after weak coupling. The result is that a large number of intermediate or jump classes are generated, which increases the complexity of the system and makes maintenance difficult.

 

6. open closed Principle)

Open/closed Principle: A software entity, such as classes, modules, and functions, should be open to extensions and closed to modifications.

The open/closed principle is open to extensions. Disabling modifications does not mean that no modifications are made. Modifications to lower-level modules must be coupled with higher-level modules. Otherwise, they are meaningless code.

There are three types of changes:

1) logical changes. Only one logic is changed, and other modules are not involved. You can modify the methods in the original class. The precondition is that all dependencies or associated classes are processed according to the same logic.

2) sub-module changes. Changes in low-level modules will inevitably lead to changes in high-level modules. Therefore, when scaling changes, high-level module modifications are inevitable.

3) view changes are visible.

How to use the open/closed principle:

1) Abstract constraints. Through interfaces or abstract classes, you can constrain a set of behavior that may change and make it open. It contains three meanings: first, the interface and abstract class are used to limit the boundaries of the extension. Public methods that do not exist in the interface or abstract class are not allowed; second, the parameter type and referenced object should try to use interfaces or abstract classes instead of implementation classes. Third, the abstraction layer remains stable and cannot be modified once determined.

2) metadata (metadata) controls module behavior.

3) formulate the project charter.

4) Encapsulation changes.

Six design principles of design patterns (I)