PHP faces 7 major principles of object

seven principles of object programming are organized:

Contents: 1. Open-closed principle

2. The principle of substitution on the Richter scale

3. Dependency Inversion principle

4. Interface Isolation principle

5. Synthetic Multiplexing Principles

6. Minimum knowledge principle/Dimitri Principle

7. Single Responsibility Principle

Here's a look at the details:

1. OCP
Full Name: "open-closed Principle" open-closed principle
Description: Open for extension, close for modification.
Advantages: The system designed according to the OCP principle reduces the coupling between each part of the program, and its adaptability, flexibility and stability are better. When existing software systems need to add new functionality, there is no need to modify the abstraction layer as the basis of the system, simply attach the new module on the original basis to achieve the required functionality. The added new modules have no effect on the original modules or have minimal impact, so there is no need to re-test the original modules.
How to implement the "open-close" principle
In object-oriented design, it is not allowed to change the abstraction layer of the system, but the implementation layer of the system is allowed to extend. In other words, define a once and for all abstract design layer, allowing as many behaviors as possible to be implemented at the implementation level.
The key to solving the problem lies in abstraction, which is the first core essence of object-oriented design.
The abstraction of a thing is essentially a generalization of its essence. Abstract let us seize the most important things, from a higher level to think. This reduces the complexity of thinking, and we don't have to think about that much at the same time. In other words, we encapsulate the nature of things and see no details.
In object-oriented programming, by means of abstract classes and interfaces, the characteristics of specific classes are defined as abstract layers, relatively stable, without change, so as to satisfy the "close to modify", and the concrete classes derived from abstract classes can change the behavior of the system, thus satisfying the "open to extended".
When you extend an entity, you do not have to change the source code or the binaries of the software. The key is abstraction.

2. LSP
Full Name: "Liskov Substitution Principle" on the Richter substitution principle
Description: Subtypes must be able to replace their base types. A software entity if you are using a base class, then when you replace the base class with a subclass that inherits the base class, the behavior of the program does not change. The software entity does not perceive the difference between a base class object and a subclass object.
Advantages: It is easy to implement the interchange of subclasses under the same parent class, and the client can be unaware.

3. DIP
Full Name: "Dependence inversion Principle" dependency inversion principle
Description: To rely on abstraction, do not rely on specifics. The client relies on abstract coupling.
Abstraction should not be dependent on detail; details should be dependent on abstraction;
To program for the interface, do not program for implementation.
Pros: Using the dependencies created by traditional procedural programming, the policy relies on detail, which is bad because the strategy is affected by the change in detail. The dependency inversion principle makes the detail and strategy dependent on the abstraction, and the stability of the system determines the stability.
How to do dependency inversion?
Coupling in an abstract way is the key to relying on the reversal principle. Abstract coupling relationships always involve concrete classes inheriting from abstract classes, and it is necessary to ensure that any reference to the base class can be converted to its subclasses, so the Richter substitution principle is based on the principle of reversal.
Although coupling at the level of abstraction is flexible, it also brings additional complexity, and if the likelihood of a specific class change is very small, then the benefits of an abstract coupling can be very limited, which can be better with concrete coupling.
Hierarchical: All well-structured object-oriented architectures have a clear hierarchical definition, with each level providing a cohesive set of services to the outside through a well-defined, controlled interface.
Dependent on abstraction: the recommendation does not depend on a specific class, that is, all dependencies in a program should terminate in an abstract class or interface. Try to do the following:
1. Any variable should not hold a pointer or reference to a specific class.
2. No class should derive from a specific class.
3. No method should overwrite an already implemented method in any of its base classes.

4. ISP
Full name: "Interface segregation Principle" interface isolation principle
Description: An interface that uses multiple-specificity features is always better than using a single total interface. From the perspective of a customer class, the dependency of a class on another class should be based on the minimum interface. An overly bloated interface is a pollution to the interface and should not force customers to rely on methods that they do not use.
Pros: When a software system function is extended, the modified pressure is not propagated to other objects.
How to implement the principle of interface isolation
Users should not be forced to rely on methods that they do not use.
1, the use of delegated separation interface.
2, the use of multi-inheritance separation interface.

5. CARP or CRP
Full name: "Composite/aggregate Reuse Principle "synthesis/polymerization multiplexing principle or" Composite reuse Principle "The principle of synthetic multiplexing
Note: If some functionality of the new object has already been implemented in another object that has already been created, try to use the functionality provided by other objects as part of the new object rather than recreating it yourself. The new objects are multiplexed into the existing functionality by delegating to these objects.
In short, use composition/aggregation as much as possible, and do not use inheritance as much as possible.
Advantages:
1) The only way to access an ingredient object from a new object is through the interface of the Component object.
2) This reuse is a black-box reuse because the inner details of the constituent objects are invisible to the new object.
3) This multiplexing supports packaging.
4) This multiplexing requires less reliance.
5) Each new class can focus on one task.
6) This multiplexing can be performed dynamically during runtime, and new objects can dynamically reference objects of the same type as the constituent objects.
7) As a means of reuse can be applied to almost any environment.
Disadvantages:
Is that there will be more objects in the system to be managed.

6. LOD or LKP
Full name: "Law of Demeter" Dimitri Principle or "Least knowledge Principle" minimum knowledge principle
Description: The object and object should be associated with as few methods as possible to avoid the intricate relationships.
How to implement Dimitri law
The main purpose of Dimitri Law is to control the overload of information, in the application of the system design should pay attention to the following points:
1) in the division of classes, a class with weakly coupled should be created. The weaker the coupling between classes, the more beneficial it is to reuse.
2) in the class structure design, each class should minimize the member's access rights. A class should not public its own property, but should provide a way to give value and assignment to the outside world to access its properties indirectly.
3) in the design of the class, whenever possible, a class should be designed to be invariant class.
4) on references to other objects, a class's reference to other objects should be minimized.

7. Single Responsibility Principle:

Introduction to the SRP (srp--single-responsibility Principle): As far as a class is concerned, one should only focus on doing one thing and only a reason that causes it to change。

The so-called duty, we can understand his function, is that the design of this kind of function should be only one, not two or more. It can also be understood that the reason for the reference change, when you find that there are two changes that will require us to modify the class, then you have to consider the withdrawal of this class. Because responsibility is an axis of change, when demand changes, the change reflects the change in the class's responsibilities. Use SRP Note: 1, a reasonable class, should have only one cause of its change, that is, a single duty;
2. It is unwise to apply the SRP or other principles without any indication of change;
3, in the actual change in demand should be applied to the principles of SRP to reconstruct the code;
4. The use of test-driven development will force us to separate unreasonable code before the design stinks;
5. If the test does not force separation of duties, the stench of rigidity and fragility becomes strong, then the code should be refactored with the facade or proxy pattern; SRP Pros: Eliminate coupling and reduce code rigidity due to changes in demand.

PHP faces 7 major principles of object