Introduction to the main design principles of design patterns

1.Single Responsibility Principle (SRP)

The "single responsibility model" literally means that the functions of a class should be "single" or specific, and many or unrelated functions cannot be arbitrarily written into a class, its accurate explanation is: "A class should have only one reason for its change ". I personally think this principle is mainly to teach us how to abstract andEncapsulationClass.
For example, for beginners, almost all of the code we have written, such as webform and winform user login, webform default. aspx. the form1.cs class and winform class do not need to write the same specific login business logic, such as database connection and query, login account and password matching, but should abstract the user class and a login method, then, winform or webform can call the login method of this class together.

2.Open-closed principle (OC)

"Open for expansion, closed for change ." That is, "in the face of requirements, changes to the program are made by adding code, rather than changing the existing code ". This principle is too important for developers who may change at any time. During the design, we should consider all kinds of changes as much as possible, and make the problem as comprehensive as possible. However, no matter how thoughtful you are, no matter how close the modules you design are, there will be some unblocking changes. Since it is unlikely to be completely closed, we must Abstract The design module and separate the change points for future "expansion ". We all hope to know the possible changes in the project before or shortly after the development work starts. In this way, we follow this principle to abstract the change points, and the program's "maintenance, scalability, "reusable and flexible" will be greatly enhanced.
For example, writing a calculator program is a classic example. We started to write an addition operation, and soon we wrote it on the client. At this time, we need to write a subtraction operation. We have to change the client class, which violates the "Change closed". Therefore, we 'd better abstract an abstract operation class operation, through the common inheritance and polymorphism features of object-oriented objects to isolate the coupling between specific addition, subtraction, multiplication, division, and other methods and the client, the requirements can still be met, but also can respond to changes.
3.LSP)
Simply put, that is, "Child types must be able to replace their parent types ". If a software object uses a parent class, it must be applicable to its subclass and cannot detect the difference between the parent class object and the subclass object. In a program, replace the parent class with its Child class, and the behavior of the program remains unchanged.
For example, during programming, we designed a fish that acts as a "swim", followed by "goldfish" and "woodenfish) "category, all inherit fish, but we can see that goldfish can obviously" swim ", but the wooden fish can only be knocked rather than" swim ", that is to say, the wooden fish cannot inherit the fish. (This example may not be suitable, as it was thought of when listening to songs)
4.Dependency reversal principle (DIP)

Before explaining this principle, let's take a look at the "dependency" that we often encounter, that is, coupling. Coupling can be divided into the following three types:
(1) Zero coupling (nil coupling) relationship. There is no dependency between the two classes, that is, zero coupling.
(2) A concrete coupling relationship. Two classes have a dependency relationship, which means a specific coupling relationship. If a specific class directly references another specific class, this relationship will occur.
(3) Abstract coupling relationship. this relationship occurs between a specific class and an abstract class, which maximizes flexibility between classes that must have a relationship. (this is also the most desired Coupling Method in our programming process)
The most classic and perfect explanation:"Programming for interfaces, not for implementation".
Dependency inversion principle: (1) High-level modules should not depend on underlying modules. Both of them should depend on abstraction. (2) Abstraction should not depend on details. Details should depend on abstraction (abstractions shocould not depend upon details. Details shoshould depend upon extends actions ). "Abstract" is usually an interface or abstract class. Here, the emphasis is on using the "inheritance" feature in object-oriented systems. Note: the premise of this principle is that the Li's replacement principle, in the program, replaces the parent class with a subclass, and the behavior of the program will not change. The parent class can be reused only when the child class can completely replace the parent class, and the Child class can also add new behaviors based on the parent class.
For example, you can also use webform user login as an example to classify users into multiple types, such as common registered users, company employees, Loyal users of different levels, VIP users, and so on. Abstract An abstract class user so that employees of different classes can inherit the user. Common users and company employees may only have the login methods in the abstract class, loyal users and VIP users of different levels expand some of their own behaviors, such as payment. In this way, you can use the parent class user to call a user of different categories. The parent class variable is equal to the new user class of a specific category.

5.Dumit rule)
Also known as the least knowledge principle (LKP), an object should have as little knowledge as possible about other objects, also known as "don't talk to strangers ". The correct explanation is that "If two classes do not need to communicate with each other directly, they should not directly interact with each other. If one class needs to call a method of another class, it can be forwarded by a third party. ". It emphasizes that when encapsulating a class, in terms of the class design structure, each class should reduce the access permissions of members. The lower the Coupling Degree between classes, the better. Because a class is modified, other associated classes are not modified.