Turn object-oriented design principles

1. Single Responsibility Principle (SRP)

The single responsibility principle (SRP) should have only one reason for its change in a class. That is to say, do not put different responsibilities for different reasons of change together, because different changes will affect irrelevant responsibilities. In other words, you don't need to worry about things you shouldn't care about. You can manage your own things, and your own things hurt others.

In software design, if a class has too many responsibilities, these responsibilities are coupled together, and a change in responsibilities may weaken and suppress the class's ability to fulfill other responsibilities. This coupling will lead to a fragile design, and when changes occur, the design will suffer unexpected damages.

What software design really needs to do is to discover responsibilities and separate them from each other. If more than one motivation is used to change a class, this class has an extra responsibility, and the separation of duties of the class should be considered.

2. The open-closed principle (OCP) Principle)

The open-closed principle, or the open-closed principle, means that software entities (classes, modules, functions, etc.) should be extensible, but cannot be modified. "You can add new classes, but do not modify the original classes ". It is much better to understand from this perspective. In fact, it is still a problem of isolation and change.

Two features of this principle: one is open to expansion, and the other is closed to changes.

When designing and developing any system, we cannot expect that the system needs to be determined from the very beginning and will not change any more (so we are so happy, haha ), this is unrealistic and unscientific. Since the demand has changed, how can we easily modify the designed program in the face of the demand changes, we need to re-launch the entire program (this will make programmers crazy, haha, you don't want to go crazy ). What kind of design can we face the changes in requirements, but it can be relatively stable, so that the system can continue to launch new versions after the first version? The principle of openness and closure is our answer.

During program design, we should always consider the best class design as much as possible, and do not modify it if it is well written. If there is a new demand, we add some classes to meet new requirements, and the original code will not move.

It is absolutely impossible to disable the modification. No matter how closed the module is, there will be some changes that cannot be closed to it. Since it cannot be completely closed, the designer must make a choice on the variant closures of the modules he designed, and he must first guess the types of changes that are most likely to change, and then construct an abstraction to isolate those changes.

The open-closed principle is the core of object-oriented design. Following this principle can bring about the huge benefits of object-oriented technology, that is, maintenance, scalability, reusability, and flexibility. Developers should only abstract the frequently changed parts of the program. Then, it is not a good idea to deliberately abstract each part of the application, rejecting immature abstraction is as important as the abstraction itself.

3. Dependency inversion principle (DIP Dependency inversion principle)

Dependency inversion principle: Abstraction should not depend on details. The details should depend on abstraction; the top should not depend on the bottom layer, and both should depend on abstraction. To put it bluntly, it is necessary to program the interface rather than implement programming. Abstract is the most stable, that is, we rely on its stability.

Dependency inversion can be said to be a sign of object-oriented design. It is not important to write a program in which language. If writing is to consider how abstract programming is not detailed programming, that is, all dependencies in the program are terminated with abstract classes or interfaces, that is, object-oriented design, and vice versa, procedural design.

4. Lee's replacement principle

LSP: The child type must replace its parent type. To put it bluntly, if a software entity uses a parent class, it must be applicable to its Child class, but it cannot detect the difference between the parent class object and the Child class object, that is, in the software, replace all the parent classes with their child classes, and the program behavior remains unchanged.

With the Rys replacement principle, it is possible to inherit and take it. Only when the child class can replace the parent class will the function of the software be unaffected and the parent class can be reused, child classes can also add new behaviors based on parent classes.

With the Li's replacement principle, the open-closed principle can be made possible. It is precisely because of the replacement of child types that the parent type modules can be expanded without modification.

5. Interface isolation principle (ISP)

Interface isolation principle (ISP): Customers should not be forced to rely on methods they do not need. An interface belongs to a customer and does not belong to its class hierarchy. This is quite clear. In other words, do not force customers to use the methods they do not use. If you force users to use the methods they do not use, then these customers will face the changes caused by the changes to these unused methods.

6. dummit's Law)

The law of Demeter (or the short-cut-level) is also called the least knowledge principle (least knowledge principle or LKP). If the two classes do not communicate with each other directly, then these two classes should not have a direct interaction. If one class needs to call a method of another class, it can be forwarded by a third party.

The premise of the dimit rule is that in the structure design of the class, each class should minimize the access permissions of members.

The fundamental idea of the dimit Law emphasizes the loose coupling between classes. The weaker the coupling between classes, the more conducive to reuse. A class with weak coupling is modified and will not affect related classes.

7. Principles of synthesis/aggregation reuse (composite/aggregate Reuse Principle or CARP)

Composite/aggregate Reuse Principle or CARP: Composite Reuse Principle or CRP ), it is to use some existing objects in a new object to make it a part of the new object. New objects reuse existing functions by delegating these objects. I want to use synthesis/aggregation whenever possible, and do not use inheritance whenever possible.