PHP design Pattern--six major principles

Statement: This series of blog reference "Big Talk design mode", author Geoscience.

It is generally considered that code that complies with the following six principles is easily extensible and reusable:

the six principles of any object-oriented language should be adhered to, in order to make your code easy to expand high-consumption as far as possible to meet the six principles, not necessarily strictly according to a design pattern, but if your code conforms to these six principles, then your code is good code, Good code is not necessarily code that is written strictly in design mode.

1. Single Responsibility

definition: Do not have more than one cause for class changes. In layman's terms, a class is responsible for only one responsibility.

Scene: Class T is responsible for two different duties: responsibility P1, Responsibility P2. when a class T needs to be modified due to a change in the duty P1 requirements, it is possible to cause the function that is normally functioning P2 to fail with the relationship such as:

Modify: follow a single responsibility principle. Set up two classes T1, T2 respectively, so that T1 complete the functions P1 function, T2 complete functions P2 function. In this way, when the class T1 is modified, the responsibility is not P2 the risk of failure, and, similarly, when T2 is modified, it does not cause the responsibility to P1 the risk of failure, structure such as:

Advantages:

1), can reduce the complexity of the class, a class is only responsible for a responsibility, logic simple;

2), improve the readability of the class, improve the maintainability of the system;

3), the risk of change caused by the reduction, change is inevitable.

2. The principle of substitution on the Richter scale

Definition: All references to the base class must be able to use the object of its subclass transparently, that is, the subclass can extend the functionality of the parent class, but not the original function of the parent class

scene: has a functionP1, by the classAcompleted. Now you need to add functionalityP1Extension , the extended function isP, wherePby the original functionP1and new featuresP2composition. New featuresPby the classAsub-classBto complete, the child classBafter completing the new featureP2may cause the original function to beP1failure occurs, such as:

The COUNTPRICEBYJKL class inherits from the Countprice class, and COUNTPRICEBYJKL overrides the Count () method, which may affect the functionality of the original Count method.

Modify: when using inheritance, follow the Richter substitution principle. When class B inherits from class a , try not to rewrite the parent class a , except to add a new method to complete new functionality P2 method, and try not to overload the parent class A the method.

3. Dependency Inversion principle

Definition: high-level modules should not be dependent on the lower layers, both should rely on their abstraction; abstractions should not depend on detail; detail should be dependent on abstraction.

This is the most difficult to understand, usually in the framework of the project to use, 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 scalable high-reuse, try not to let the business logic layer depends on the data layer, An interface can be abstracted from the data layer, allowing the business logic layer to rely on this abstract interface.

         Scenario: dependency class If you want to change class A to a dependent class c (Low-level module),

The Autosystem class is directly dependent on the Hondacar and Fordcar two classes, resulting in a high coupling, autosystem classes want to manipulate Hondacar or fordcar must create the corresponding object directly.

Modify: Modify Class A to dependent interface I, Class B and Class C each implement interface I, Class A through interface I indirectly with Class B or Class C, it will greatly reduce the chance to modify Class A, such as:

After this modification, Honda and Ford implemented the ICAR interface, providing the run, stop, and turn function methods, Autosystem dependent icar interface, forcing Autosystem to rely on the abstract interface, This allows the Autosystem class to cope with more demand changes.

Advantages:

1), low-level modules as far as possible to have an abstract class or interface , or both.

2), the declaration type of the variable as far as possible is abstract class or interface.

3), the use of inheritance to follow the Richter replacement principle.

4. Interface Isolation principle

Definition: The client should not rely on interfaces it does not need, and the dependency of one class on another should be based on the smallest interface.

Scenario: Class A relies on class B through interface I, Class C through interface I relies on Class D, and if interface I is not the smallest interface for Class A and Class B, then Class B and Class D must implement methods that they do not need, such as:

　　　　　　　　

Modify: Split the bloated interface I into separate interfaces, and Class A and Class C are dependent on the interfaces they need. That is, the principle of interface isolation.

　　　　　　　　　　

Attention:

1 ), the interface as small as possible, but to have a limit . The refinement of the interface can improve the design flexibility is not a fact, but if too small, it will result in an excessive number of interfaces, resulting in complex designs. So be sure to be modest.

2), to customize the service for the interface-dependent class, exposes only to the calling class the method it requires, and the method it does not need is hidden. A minimal dependency can be established only by focusing on providing a customized service for a module.

   3), improve cohesion, reduce external interaction. Enable the interface to do the most things with the least amount of method .

　　5. Dimitri rule (least known principle)

Definition: An object should have minimal knowledge of other objects.

Scene: 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 simple understanding is that cohesion, a class of methods and properties can be privatized as far as possible with private.

Attention:

1 only communicate with a direct friend and don't talk to strangers.

2 ), the excessive use of this principle, will lead to greater complexity of the system. Therefore, in the adoption of Dimitri Law, we should weigh repeatedly, not only to achieve a clear structure, but also high cohesion and low coupling.

6. Opening and closing principle

Definition: a software entity such as classes, modules, and functions should be open to extensions and closed for modification .

Scene: During the software lifecycle, because changes, upgrades, and maintenance are required to modify the original code of the software, errors may be introduced into the old code, or we will have to refactor the entire functionality and require the original code to be re-tested .

Recommendation: When software requirements change, try to make changes by extending the behavior of the software entities, rather than by modifying existing code.

PHP design Pattern--six major principles