Seven Principles of object programming and seven principles of object programming

Seven Principles of object programming and seven principles of object programming
Seven Principles of object programming:

1. OCP
Full name: "Open-Closed Principle" Open-Closed Principle
Note: It is open to extensions and closed to modifications.
Advantages: the system designed according to the OCP principle reduces the coupling between various parts of the program, and has good adaptability, flexibility, and stability. When new functions need to be added to an existing software system, you do not need to modify the abstraction layer as the system base, you only need to add a new module on the original basis to implement the required functions. The new module has no influence on the original module or has little impact, so you do not need to re-test the original module.
How to implement the "open-close" Principle
In object-oriented design, the abstraction layer of the system is not allowed to be changed, but the Implementation Layer of the system is allowed to be extended. In other words, define an abstract design layer once and for all to allow as many actions as possible to be implemented at the implementation layer.
The key to solving the problem lies in abstraction. abstraction is the first core essence of object-oriented design.
Abstract A thing is, in essence, a summary of its essence. Abstract Let us grasp the most important thing and think from a higher layer. This reduces the complexity of thinking. We don't need to consider so many things at the same time. In other words, we encapsulate the essence of things and cannot see any details.
In object-oriented programming, abstract classes and interfaces are used to specify the features of a specific class as the abstract layer. This layer is relatively stable and does not need to be changed, so as to "Disable modification "; the specific class exported from the abstract class can change the behavior of the system to meet the requirement of "open to extension ".
You do not need to modify the source code or binary code of the software when you expand an object. The key lies in abstraction.

2. LSP
Full name: "Liskov Substitution Principle"
Note: child types must be able to replace their base types. If a software entity uses a base class, the program behavior will not change if the base class is replaced with a subclass that inherits the base class. The software entity does not notice the difference between a base class object and a subclass object.
Advantage: it is easy to implement the interchange of sub-classes under the same parent class, and the client can not notice it.

3. DIP
Full name: "Dependence Inversion Principle" Dependency Inversion Principle
Note: It depends on abstraction rather than specifics. The client depends on abstract coupling.
Abstraction should not depend on details; details should depend on abstraction;
Programming for interfaces is not implemented.
Advantage: The dependency relationships created by traditional procedural programming are dependent on details, which is poor because the policies are affected by changes in details. The dependency inversion principle makes the details and policies depend on abstraction. The stability of abstraction determines the stability of the system.
How can we put the dependency upside down?
Coupling in an abstract way is the key to the dependency reversal principle. Abstract Coupling Relationships always involve the inheritance of a specific class from an abstract class, and must be ensured that the class can be changed to its subclass in any reference to the base class. Therefore, the Li's replacement principle is the basis of the reversal principle.
Coupling at the abstract level is flexible, but it also brings additional complexity. If a specific class is less likely to change, the benefits of abstract coupling are very limited, in this case, coupling is better.
Hierarchical: all well-structured object-oriented architectures have clear hierarchical definitions, and each layer provides services in a group through a well-defined and controlled interface.
Dependent on Abstraction: We recommend that you do not rely on specific classes, that is, all dependencies in the program should end with abstract classes or interfaces. Try:
1. No variable should hold a pointer or reference pointing to a specific class.
2. No class should be derived from a specific class.
3. No method should overwrite the implemented methods in any of its base classes.

4. ISP
Full name: "Interface Segregation Principle" Interface isolation Principle
Note: interfaces with multiple specific functions are always better than interfaces with one function. From the perspective of a customer class: the dependence of a class on another class should be based on the minimum interface. Interfaces that are too bloated are contaminated and should not be forced to rely on methods they do not need.
Advantage: When a software system is extended, the modification pressure will not be transferred to other objects.
How to Implement the interface isolation principle
Users should not be forced to rely on methods they do not need.
1. Use the delegate isolation interface.
2. Use the multi-inheritance isolation interface.

5. CARP or CRP
Full name: "CompositE/Aggregate Reuse Principle "or" Composite Reuse Principle"Merging Reuse Principle 
NOTE: If some functions of the new object have been implemented in other created objects, try to use the functions provided by other objects to make them part of the new object, instead of re-creating it on your own. New objects reuse existing functions by assigning them.
In short, we should try to use synthesis/aggregation instead of inheritance.
Advantages:
1) The only way for a new object to access a component object is through the component object interface.
2) This reuse is black box reuse, because the internal details of the component object are invisible to the new object.
3) This reuse supports packaging.
4) This reuse requires less dependencies.
5) each new class can focus on a task.
6) This reuse can be performed dynamically during the running time. New objects can dynamically reference objects of the same type as component objects.
7) as a means of reuse, it can be applied to almost any environment.
Disadvantages:
That is, many objects need to be managed in the system.

6. DLE or LKP
Full name: "Law of Demeter" dimit Principle or "Least Knowledge Principle" Minimum Knowledge Principle 
Note: objects and objects should be associated using as few methods as possible to avoid link relationships.
How to Implement the dimit rule
The primary purpose of the dummit rule is to control information overload. When applying it to system design, pay attention to the following points:
1) The division of classes should create classes with weak coupling. The weaker the coupling between classes, the more conducive it is to reuse.
2) In the structure design of classes, each class should minimize the access permissions of members. A class should not have its own public attributes. Instead, it should provide a method of value and value assignment to allow the outside world to indirectly access its own attributes.
3) in the design of classes, a class should be designed as a constant class as long as possible.
4) When referencing other objects, the reference of a class to other objects should be minimized.

7. Single responsibility principle:

SRP introduction (SRP -- Single-Responsibility Principle): For a class, you should focus only on one thing and only one reason for its change.. The so-called responsibility, we can understand it as a function, that is, this class function should have only one, not two or more. It can also be understood as the reason for referencing changes. When you find that two changes require us to modify this class, you should consider removing this class. Because responsibility is an axis of change, when the demand changes, this change will reflect the changes in class responsibilities. Note when using SRP: 1. A reasonable class should have only one reason for its change, that is, a single responsibility;
2. It is unwise to apply the SRP or other principles without any signs of change;
3. the SRP principle should be applied to reconstruct the code when the actual requirement changes;
4. Using test-driven development forces us to separate unreasonable code before the design smells bad;
5. If the test cannot force separation of duties, and the odor of rigidity and vulnerability will become very strong, We Should refactor the code in Facade or Proxy mode; SRP advantages: eliminate coupling, reduce code Rigidity caused by demand changes

 

These are obtained from the Internet and I don't understand them, because I just learned this.