Design Patterns series (1) Five design principles of design patterns

Here I have summarized the five design principles of the design model. Of course, there may be more than these five, but here I will summarize the five most common and commonly used design principles. The design principle is the goal of our software design, and the design pattern is our specific practice.

I. Single Responsibility Principle (SRP ):

1. SRP (single responsibilities principle) Definition: for a class, there should be only one cause of its change. In shortSingle Function.

2. If a class has too many responsibilities, it is equivalent to coupling these responsibilities. A change in responsibilities may weaken or suppress the class's ability to fulfill other responsibilities. This coupling will lead to a fragile design. When a change occurs, the design will suffer unexpected damages. (Agile Software Development)

3. What software design really needs to do is to discover responsibilities and separate them from each other. (Agile Software Development)

Ii. Open-Close principle (OCP ):

1. Definition of OCP (Open-Close principle): that is, the software entity (class, method, etc.) shouldCan be expanded, but cannot be modified. It is also the most important design principle in software design.

2. Two OCP features:

1> It is open for expansion.

2> the modification is closed.

3. When Will OCP principles be applied?

When we first write the code, we assume that the changes will not happen. When the changes happen, we create an abstract (such as an abstract class or interface) to isolate similar changes that will happen in the future.

4. The open-closed principle is the core of object-oriented design. Following this principle can bring about the huge benefits that object-oriented technology claims, that is, maintenance, scalability, reusability, and flexibility. Developers should only abstract those parts that present frequent changes in the program. However, it is also not a good idea to deliberately abstract each part of the application. Rejecting immature abstractions is just as important as abstraction itself.

5. ocp uml diagram:
　　

Iii. Dependency reversal principle (DIP ):

1. Definitions of DIP (dependence inversion principle): Abstraction should not depend on details, and details should depend on abstraction. Simply put, we need to program the interface instead of the implementation.

Negative example UML diagram:

　　

Disadvantage: the High-Level module is too dependent on the low-level module, and the coupling is too tight. Changes to the lower-level modules will affect the upper-level modules.

Solution: Use the Dependency inversion principle to make the high-level and low-level modules depend on abstraction (interfaces or abstract classes ).

The modified UML diagram is as follows:

　　

Advantage: modifying the lower-level modules will not affect the upper-level modules, reducing the Coupling Degree between them and enhancing the system stability.

Conclusion: The dependency inversion principle can be said to be a sign of object-oriented design. It is not important to use the language to compile the program. If the programming is based on abstract programming rather than detailed programming, that is, all dependencies in the program are terminated from abstract classes or interfaces, that is, object-oriented design, and vice versa, that is, procedural design.

Iv. Lean replacement principle (LSP ):

1. Definition of LSP (liskov substitution principle): child types must be able to replace their parent types. Simply put, this is because the child type inherits the parent class, so the child class can appear as the parent class.

Instance UML diagram:

Implemented C # code:

public class Animal    {        public void Eat() { }        public void Drink() { }        public void Run() { }        public void Shout() { }    }    public class Cat : Animal    { }    public class Dog : Animal    { }    public class Cattle : Animal    { }    public class Sheep : Animal    { }

Class program {static void main (string [] ARGs) {animal = new CAT (); // you can replace it with dog, cattle, or sheep as required, the program does not need to change animal elsewhere. eat (); animal. drink (); animal. run (); animal. shout ();}}

Conclusion: It is precisely because of the Lee's replacement principle that inheritance reuse is possible. Only when the child class can replace the parent class and the functions of the software unit are not affected can the parent class be reused. The Child class can also add new behaviors based on the parent class.

V. dummit's law (with a level of detail ):

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

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, do not disclose fields or actions (methods) that other classes know.