Six principles of design patterns

Six principles in Design Patterns

ISingle Responsibility Principle

1,

Singleresponsibilityprinciple (SRP) has only one reason for its change in a class.

2, Description

Excessive class responsibilities = coupling the responsibilities together may lead to the entire body, resulting in the class being unable to fulfill other responsibilities. This high coupling will lead to fragile design and unexpected damages. (Relations between the United Nations and various countries in the intermediary model ).

3Single responsibility principle will bring those effects to programming

With a single responsibility, the code is easy to maintain, scalable, reusable, and flexible.

4, Under what circumstances can we consider separation of duties?

When a class has multiple motivations, such classes assume multiple responsibilities and should consider separation of duties. (A lot of work in software design is to discover and separate duties)

5, Application

The mobile phone interface is separated from the game logic. When you change the interface one day, the game itself remains unaffected and can be reused.

 

Ii. Openness-Blocking Principle

1,

Theopen-closedprinciple (OCP) indicates that software entities (such as classes, modules, and functions) can be expanded but cannot be modified. [ASD]

2, Description

It is unrealistic not to expect the system to determine the requirements at the beginning when it is used for any system. Since the demand must be changed, how can we make the design software relatively easy to modify, so that the whole program will not be re-launched as new requirements arise. What kind of design can be relatively stable in the face of changes in demand? The open-closed principle gives us the answer.

3Open-What will the blocking principle bring to programming?

The open-closed principle is the core of object-oriented design. The biggest benefit is maintainability, scalability, reusability, and flexibility.

4, Under what circumstances can this principle be considered

Developers should only abstract the frequently changed parts of the program. However, every part of the application is deliberately abstracted. Rejecting immature abstractions is equally important as abstracting itself. When the demand changes, we want to meet the demand through expansion, instead of modifying the original code, we need to consider this principle.

5, Application

Two mistakes for postgraduate entrance exams; one country and two systems of Deng Xiaoping

Iii. Li's replacement principle

1,

Liskov substitutionprinciple (LSP): child types must be able to replace their parent types. Because the child type can be replaced, the module of the parent class can be expanded without modification.

 

2, Description

Generally speaking, a subclass can extend the function of the parent class, but it cannot change the original function of the parent class.

If a software entity uses a parent class, it must be applicable to child classes and cannot detect the differences between parent class objects and Child class objects. That is to say, in the software, replace the parent class with its subclass. The program does not change.

3What effects does the Li's replacement principle bring to programming?

Only when the child class is replaced with the parent class and the functions of the software unit are not affected can the parent class be reused. The Child class can add new behaviors on the basis of the parent class, it is precisely because of the Li's replacement that inheritance reuse is possible. It is precisely because the module in the parent class can be extended without any modifications. Otherwise, let's talk about extended openness and closed modification.

5, Application

For example, in object-oriented design, child classes have all non-private behaviors and attributes of the parent class. Birds fly, but penguins do not fly, so they cannot inherit birds.

 

Iv. Dependency reversal Principle

1,

Dependence inversionprinciple: A. The high-level module should not depend on the underlying module. Both of them should depend on abstraction.

B. abstraction should not depend on details. Details should depend on abstraction.

2, Description

Core Principles of dependency reversal:Interface-Oriented Programming, Do not program. Taking computer components as an example, no matter whether the motherboard, cup, memory, or hard disk are designed for the interface, if the implementation is designed, the memory should correspond to the motherboard of a specific brand, if you change the memory, you need to change the motherboard. In this way, damage to any part will cause unavailability of the entire motherboard. This will cause heavy losses. If the interface is used, as long as the interface is stable, if a part is broken, it will be replaced with the corresponding part without affecting other parts.The principle of dependency inversion is based on the fact that abstract things are much more stable than the variability of details.

3And what effects does Dependency inversion bring to programming?

It achieves high cohesion and low coupling, making the program easy to maintain, easy to expand, easy to reuse, and flexible and diverse.

4, Under what circumstances can this principle be considered

Abstract dependency abstraction, and so on, note that when using inheritance, we should follow the Li's replacement principle. In the case of abstract dependency, the application of this principle should be considered.

5, Application

Hardware devices in the computer, such as CPU connections to the motherboard through pins, and memory stick, all use interfaces.

 

 

V. dimit's Law

1,

Law of Demeter: If two classes do not need to communicate with each other directly, they should not have a direct relationship. If one class needs to call a method of another class, it can be forwarded by a third party.

2.Description

The premise of the dimit rule is that in the structure design of classes, each class should minimize the access permissions of members. That is to say, a class encapsulates its own private State, and should not disclose fields or behaviors that do not need to be known to others. If needed, it is implemented through attributes.

The fundamental idea of the dimit law is to emphasize the loose coupling between classes.

3Benefits

The weaker the coupling between classes, the more conducive to reuse. A class with weak coupling is modified and will not affect related classes. Information Hiding promotes the reuse of software.

4Simple Application

Find the IT department to repair the computer, just find the IT department head all OK. Do not look for a specific repairer in the IT department. The IT department is abstract.

 

6. Synthesis/Principle of aggregation Reuse

1,

Composite/Aggregate
Reuse Principle, CARP), try to use synthesis/aggregation, and try not to use class inheritance.

2, Description

Both composition and aggregation are associated special types. Aggregation indicates a weak "having" relationship. It indicates that object A can contain object B, but object B is not part of object; synthesis is a kind of strong "possession", which reflects the relationship between the strict part and the whole. The whole part is born at the same time and perish at the same time.

3Benefits

It will help you keep each class encapsulated and concentrated on a single task. In this way, the Class and Class inheritance layers will remain relatively small and are unlikely to grow into an uncontrollable giant.

4Simple Application

PC is a combination of hardware and software.