PHP's design pattern

1. Single Responsibility Principle

Single Duty principle (Responsibility Principle)

Meaning: 1. Avoid spreading the same duties into different classes, 2. Avoid a class that takes on too much responsibility;

Benefits of SRP: reduced coupling between classes to improve class reusability

Actual use:

1. Extract business objects from business processes
2. Classification of duty of attention

The idea of a single responsibility principle should not only be used in class, but also in the method of class, which means that the logic of a method should not be too complicated, but should separate the different logic, and finally simplify the function of the method and improve the readability of the code. For example, a user submits a request, We need a simple validation of its parameters, so the logic of this validation can separate several different ways to handle it individually:

2. Interface Isolation principle

The interface Isolation principle (Interface segregation Principle, abbreviation: ISP), the client should not rely on the interface it does not need, and the dependency of one class on another should be based on the smallest interface.

Using multiple specialized interfaces is better than using a single total interface. The dependency of a class on another class should be based on the smallest interface. An interface represents a role, and different roles should not be handed over to an interface. Interfaces that are not related are combined to form a bloated, large interface that is polluting the roles and interfaces. "Customers should not be forced to rely on methods that they do not use. The interface belongs to the customer and does not belong to the class hierarchy in which it resides. In layman's terms, don't force clients to use methods they don't use, and if they force users to use methods they don't, then these customers will face changes due to changes in these unused methods.

3. Open-Close principle

Open Close Principle, abbreviation: OCP, objects in the software (classes, modules, functions, etc.) should be "opened" to the extension, but are "closed" for modification. The popular point is that the various components contained in the software system should introduce new features without modifying the existing code. "On" is an extension of the function of the component is open,
is allowed to extend its functionality; "Closed" is the modification of the original code is closed, that is, the original code should not be modified.

Characteristics:

Make the program more stable and flexible: 1. For extensions to be open: when the requirements of the application change, we can extend the module so that it has new behavior that satisfies those changes. In other words, we can change the function of the module. 2. For the modification is closed: When the module behavior is extended, you do not have to change the module source code or binary code.

4. Replacement principle

The Richter replacement principle (Liskov Substitution Principle, abbreviation: LSP), where the principle says any base class can appear, subclasses must be able to appear. LSP is the cornerstone of inheritance reuse, only if the derived class can replace the base class, the function of the Software unit is not affected, the base class can be really reused, and the derived class can also add new behavior on the basis of the base class.

The core principle of the Richter replacement principle is abstract, abstract and dependent on the inheritance of this feature, in OOP, the advantages and disadvantages of inheritance is quite obvious, mainly the following points Pros: 1. Code reuse reduces the cost of creating classes, each of which has methods and properties of the parent class; 2. Subclasses are basically similar to the parent class, but differ from the parent class; 3. Improve the extensibility of the code. Cons: 1. Inheritance is intrusive, as long as inheritance must have all the properties and methods of the parent class; 2. The subclass code can be redundant and less flexible because subclasses must have properties and methods of the parent class.LSP: It is mainly about inheritance design principles

5. Dependency Inversion principle

The dependency inversion principle (dependence inversion Principle, abbreviation: DIP) is that the program relies on an abstract interface and does not rely on a specific implementation. Simply put, it requires programming the abstraction, not programming the implementation, which reduces the coupling between the customer and the implementation module. Principle 1. high-level modules should not be dependent on low levels of modules, they should all rely on abstraction. The upper modules should not be dependent on the underlying modules, they all depend on an abstraction (the parent class cannot depend on the subclass, they all depend on the abstract class)2. Abstractions should not depend on concrete implementations, but concrete implementations should be dependent on abstractions.

6. Minimum knowledge principle

The Dimitri principle (law of Demeter, abbreviation: LoD), also known as the least knowledge principle (Least knowledge Principle, abbreviated LKP), means that an object should have as little understanding of other objects as possible.

Principle a class should know the least about the classes that it needs to be coupled or called, how the inner implementation of the class does not matter to the caller or the relying person, the caller or the relying person needs only to know the method it requires, and the others can do nothing. The closer the relationship between classes and classes, the greater the coupling, and the greater the impact on another class when one class changes. The Dimitri law can be simply said: Talk is only your immediate friends. That is, "communicate only with direct friends". As for what is a direct friend? Each object is bound to have a coupling relationship with other objects, and the coupling between two objects becomes a friend, and there are many types of relationships, such as composition, aggregation, dependency, etc.

PHP's design pattern