Home > Article > Backend Development > PHP Design Patterns - Six Principles_PHP Tutorial
PHP Design Patterns - Six Principles_PHP Tutorial
- WBOYOriginal
- 2016-07-13 09:57:42905browse
PHP Design Patterns - Six Principles
It is generally believed that code that follows the following six principles is easy to expand and reusable:
Any object-oriented language should abide by these six principles. If you want to make your code easy to expand and use, try to meet these six principles. It does not necessarily have to strictly follow a certain design pattern, but if your code If the code complies with these six principles, then your code is good code. Good code is not necessarily code written strictly in accordance with the design pattern.
1. Single responsibility
Definition: Do not have more than one reason for a class change. In layman's terms, a class is only responsible for one responsibility.
Scenario: Class T is responsible for two different responsibilities: responsibility P1 and responsibility P2. When class T needs to be modified due to changes in the requirements of responsibility P1, it may cause the function of responsibility P2 that was originally running normally to malfunction. The relationship is as follows:
Modification: Follow the single responsibility principle. Create two classes T1 and T2 respectively, so that T1 can complete the responsibility P1 function and T2 can complete the responsibility P2 function. In this way, when class T1 is modified, responsibility P2 will not be at risk of failure; similarly, when T2 is modified, responsibility P1 will not be at risk of failure. The structure is as follows:
Advantages:
1) It can reduce the complexity of classes. Each class is only responsible for one responsibility and the logic is simple;
2), improve the readability of classes and the maintainability of the system;
3) Risks caused by changes are reduced. Changes are inevitable.
2. Richter Substitution Principle
Definition: All places that reference a base class must be able to transparently use objects of its subclass, which means that subclasses can extend the functions of the parent class, but cannot change the original functions of the parent class
Scenario: There is a function P1, completed by class A. Now it is necessary to expand the function P1, and the expanded function is P, where P consists of the original function P1 and the new function P2. The new function P is completed by the subclass B of class A. When subclass B completes the new function P2, it may cause the original function P1 to malfunction, as shown below:
The CountPriceByJKL class inherits from the CountPrice class. CountPriceByJKL overrides the Count() method, which may affect the function of the original Count method.
Modification: When using inheritance, follow the Liskov substitution principle. When class B inherits class A, except for adding new methods to complete the new function P2, try not to override the methods of parent class A, and try not to overload the methods of parent class A.
3. Dependency Inversion Principle
Definition: High-level modules should not depend on low-level modules, both should rely on their abstractions; abstractions should not depend on details; details should depend on abstractions.
This is the most difficult to understand. It is generally used when building the project framework. For example, the business logic layer is a high-level module relative to the data layer, because the business logic layer needs to call the data layer to connect to the database, but To achieve scalability and high reuse, try not to let the business logic layer depend on the data layer. You can abstract an interface in the data layer and let the business logic layer depend on this abstract interface.
Scenario: Class A (high-level module) directly depends on class B (low-level module). If you want to change class A to depend on class C (low-level module), you must modify the code of class A. In this scenario, class A is generally a high-level module responsible for complex business logic; classes B and C are low-level modules responsible for basic atomic operations; if class A is modified, it will bring unnecessary risks to the program.
The AutoSystem class directly depends on the HondaCar and FordCar classes, which creates a high coupling. If the AutoSystem class wants to control HondaCar or FordCar, it must directly create the corresponding object.
Modification: Modify class A to depend on interface I. Class B and class C each implement interface I. Class A indirectly contacts class B or class C through interface I. This will greatly reduce the chance of modifying class A, as follows Picture:
After this modification, Honda and Ford implemented the ICar interface, providing Run, Stop and Turn function methods. AutoSystem relies on the ICar interface, which forces AutoSystem to rely on abstract interfaces, which enables the AutoSystem class to cope with more changes in requirements.
Advantages:
1) Low-level modules should have abstract classes or interfaces, or both.
2) The declared type of the variable should be an abstract class or interface as much as possible.
3). Follow the Liskov substitution principle when using inheritance.
4. Interface isolation principle
Definition: The client should not rely on interfaces it does not need; the dependence of one class on another class should be based on the smallest interface.
Scenario: Class A depends on class B through interface I, and class C depends on class D through interface I. If interface I is not the minimum interface for class A and class B, then class B and class D must implement they do not need to The method is as shown below:
Modification: Split the bloated interface I into several independent interfaces, and class A and class C establish dependencies with the interfaces they need respectively. That is to say, the principle of interface isolation is adopted.
Note:
1) The interface should be as small as possible, but within limits. It is a fact that refining the interface can improve programming flexibility, but if it is too small, it will cause too many interfaces and complicate the design. So it must be done in moderation.
2) Customize services for classes that rely on interfaces, exposing only the methods it needs to the calling class, and hiding the methods it doesn’t need. Only by focusing on providing customized services for a module can minimal dependencies be established.
3) Improve cohesion and reduce external interaction. Make the interface use the fewest methods to accomplish the most things.
5. Demeter’s Law (Least Known Principle)
Definition: An object should keep minimal knowledge about other objects.
Scenario: The closer the relationship between classes, the greater the degree of coupling. When one class changes, the greater the impact on the other class.
The simple understanding is high cohesion. If the methods and attributes of a class can be made private, try to make them as private as possible.
Note:
1) Only communicate with direct friends and do not talk to strangers.
2) Excessive use of this principle will lead to increased system complexity. Therefore, when adopting Dimit's Law, you must repeatedly weigh the trade-offs to achieve both a clear structure and high cohesion and low coupling.
6. Opening and closing principle
Definition: A software entity such as a class, module, and function should be open for extension and closed for modification.
Scenario: During the life cycle of the software, when the original code of the software needs to be modified due to changes, upgrades, maintenance, etc., errors may be introduced into the old code, or we may have to redo the entire function. structure, and the original code needs to be retested.
Recommendation: When software requirements change, try to achieve changes by extending the behavior of software entities rather than by modifying existing code.