PHP design pattern zero in the series "You can understand it at a glance"

Friendly links:
1. Understand at a glance series of PHP design patterns (1)
2. Understand at a glance series of PHP design patterns (2)

Foreword

This article was written after I finished writing the three design patterns. The reason is that I got some more design patterns today. Principles, whether it is design patterns or the code that everyone usually writes, will be inadvertently used and followed. I plan to write it in my own words.

Design Pattern Principles You Don’t Know

Single Responsibility Principle

Definition

Don’t have more than one reason for a class change. In layman's terms, a class is only responsible for one responsibility.

Vernacular understanding

Those who can divide and collaborate should try their best to divide the work well, each is responsible for his own piece, and just do it well to avoid mutual influence.

The Liskov Substitution Principle

Definition

All places that reference a base class must be able to transparently use the objects of its subclasses, that is to say, subclasses can extend the functions of the parent class, but cannot change the original features of the parent class. Function

Vernacular understanding

When inheriting a class written by predecessors, try not to overwrite and overload the methods inside, because you don’t know where it will be affected. Inheritance methods also try to respect the original logic and not change it easily.

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.

Vernacular understanding

The parent module does not depend on each other and its sub-modules. It is best to rely on third parties (abstract classes), which can avoid the pit of high coupling. In case of product strategy changes, it can also be easily expanded horizontally ( Let’s use another subclass that inherits the abstract class) to solve the problem. If you inherit, follow the Liskov substitution principle

Interface isolation principle

Definition

The client should not rely on interfaces it does not need; one class is dependent on another class Dependencies should be built on the smallest interface.

Vernacular understanding

If you are programming through an interface, do not put a bunch of abstract methods in the interface class. This will cause the inherited class to implement methods that do not belong to it at all, even if it is an interface. Also try to outline according to the concept of total score. Common ones should be written in an interface class, individually customized ones should be written separately, and subclasses can selectively inherit the interface class.

Demeter's Law

Definition

An object should keep the minimum knowledge about other objects.

Vernacular understanding

The typical truth is that if you know too much, you are more likely to die. When you put it in the code, try to divide it into parts as much as possible when writing a module. The more couplings a module contains, the greater the coupling and the easier it is to make mistakes. If it is broken into independent modules, even if something goes wrong, it will not completely collapse.

Open-Closed Principle

Definition

A software entity such as a class, module, and function should be open for extension and closed for modification.

Vernacular understanding

When product requirements change, try to achieve changes by extending the behavior of software entities (adding classes, adding methods), rather than by modifying existing code.

Discussion of a problem

很多优化的地方都在说：高内聚低耦合，那么问题来了，高内聚低耦合真的好吗？

My opinion is: it depends on the specific logic of the business. Because of high cohesion and low coupling, once a certain piece of business is interrelated and complex, it will directly lead to the existence of many independent code blocks, even if there are Note, looking at the code will give people a feeling of jumping around, which will reduce readability, which will directly lead to reduced maintainability. When the code is handed over to others, future generations will spend a lot of time understanding the code, making it difficult to move forward. I heard that proper coupling code and chunking according to specific dependencies are better~
It is also wrong to simply write code according to the abstract specifications summarized by predecessors. Good design patterns are modified step by step, rather than designed from the beginning.

Welcome to leave a message and share

').addClass('pre-numbering').hide(); $(this).addClass('has-numbering').parent().append($numbering); for (i = 1; i ').text(i)); }; $numbering.fadeIn(1700); }); });

The above introduces the PHP design pattern zero in the series that you can understand at a glance, including the content. I hope it will be helpful to friends who are interested in PHP tutorials.