Six principles of design patterns-Simple Review

Principles of design patterns single responsibility principles

For a single responsibility, each class is only responsible for one function, or each class is only responsible for one responsibility. This will not affect too many contacts when you need to modify it,

Rys replacement principle

Definition 1:If there is an object O2 of Type T2 for every object O1 of Type T1, so that all program P defined by T1 can be replaced by O2 for all object O1, if the behavior of program P does not change, Type T2 is the child type of Type T1.

Definition 2:All objects that reference the base class must be transparently used.

 

 

The relationship between the parent class and the Child class is described here. When the Child class inherits the parent class, following the following rules will reduce the chance of errors:

1. When the subclass inherits the parent class, do not override the methods implemented by the parent class. You can add new methods to the subclass.

2. If the subclass needs to override the method of the parent class, the shape parameter of the subclass method must be more relaxed for the shape parameter of the parent class, and the return value of the subclass must be more detailed and stricter than that of the parent class.

3. sub-classes can implement abstract methods of parent classes, but cannot overwrite non-Abstract methods of parent classes.

 

Principle of dependency

Definition:High-level modules should not depend on low-level modules, both of which should depend on their abstraction; abstraction should not rely on details; details should rely on abstraction.

Problem:Class A directly depends on Class B. To change Class A to dependent Class C, you must modify the code of Class. In this scenario, Class A is generally a high-level module responsible for complex business logic; class B and class C are low-level modules responsible for basic atomic operations; if Class A is modified, it brings unnecessary risks to the program.

Solution:Change Class A to dependent interface I. class B and class C implement interface I. Class A indirectly associates with Class B or Class C through interface I, this greatly reduces the chance of modifying Class.

The principle of dependency inversion is based on the fact that abstract things are much more stable than the variability of details. The architecture built on the basis of abstraction is much more stable than the architecture built on the basis of detail. In Java, abstraction refers to interfaces or abstract classes. The details are specific implementation classes. The purpose of using interfaces or abstract classes is to formulate specifications and contracts without involving any specific operations, assign the task of displaying details to their implementation class.

1. The lower-layer modules should have abstract classes or interfaces, or both.

2. The declaration type of variables should be abstract classes or interfaces.

3. Use inheritance in accordance with the Lee's replacement principle.

Interface separation principle

Definition:The client should not rely on interfaces that it does not need; the dependency of one class on the other class should be built on the smallest interface.

Problem:Class A relies on Class B through interface I, and class C relies on Class D through interface I. If interface I is not the smallest interface for Class A and Class B, then class B and class D must implement the methods they do not need.

Solution:Split bloated interface I into several independent interfaces. Class A and Class C establish dependencies with the interfaces they need. That is, the interface isolation principle is adopted.

For example, describe the interface isolation principle:

The minimum number of interfaces is used to solve many things, and the number of interfaces requires the support of practical experience. Generally, they are mainly subdivided.

 

Dimit Law

Definition:An object should have a minimum understanding of other objects.

Problem:The closer the relationship between classes, the greater the coupling degree. When a class changes, the greater the impact on the other class.

Solution:Minimize coupling between classes.

Since we started to engage with programming, we have learned the general principles of software programming: low coupling and high cohesion. Both process-oriented and object-oriented programming can improve the code reuse rate only when the coupling between modules is as low as possible. The advantage of low coupling is self-evident, but how can we program to achieve low coupling? That is exactly what the Demeter rule is about to accomplish.

 

Principle of opening/closing

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

Problem:During the software life cycle, errors may be introduced to the Old Code when the original code of the software needs to be modified due to changes, upgrades, maintenance, and other reasons, it may also cause us to have to refactor the entire function and re-test the original code.

Solution:When the software needs to change, try to implement changes by extending the behavior of the software entity, rather than modifying the existing code.

While complying with the above five principles, the principle of opening and closing has been followed, and vice versa.

The principle of opening/closing is simply to express the following meanings:Use abstraction to build a framework and implement extended details.