Overview of PHP design patterns

Design pattern (Design pattern)

Design pattern (Design pattern) is a set of classification and cataloging summary of code design experience that is used repeatedly, known to most people. The purpose of using design patterns is to reuse code, make the code easier to understand by others, and ensure code reliability. There is no doubt that design patterns are win-win for oneself, others and the system; design patterns make coding truly engineering; design patterns are the cornerstone of software engineering, just like the structure of a building.

Why should we advocate Design Pattern?

The fundamental reason is to reuse code and increase maintainability.

So how can we achieve code reuse? There are several object-oriented principles: Open Closed Principle (OCP), Liskov Substitution Principle (LSP), Dependency Inversion Principle (DIP), Interface Segregation Principle, ISP), Composite/Aggregate Reuse Principle (CARP), Principle of Least Knowledge (PLK, also called Demeter's Law). The opening and closing principle is idealistic and is the ultimate goal of object-oriented design. Several other items can be seen as implementation methods of the opening and closing principle.

Design patterns implement these principles to achieve code reuse and increase maintainability.

23 patterns

Design patterns are divided into three types, a total of 23 types:

Abstract Factory(Abstract Factory Pattern): Provides an interface for creating a series of related or interdependent objects without specifying their concrete classes.

Adapter (Adapter pattern): Convert the interface of a class into another interface that the customer wants. The Adapter pattern enables classes that would otherwise not work together due to incompatible interfaces to work together.

Bridge (Bridge mode): Separate the abstract part from its implementation part so that they can change independently.

Builder (Builder pattern): Separate the construction of a complex object from its representation, so that the same construction process can create different representations.

Chain of Responsibility (Chain of Responsibility pattern): To decouple the sender and receiver of the request so that multiple objects have the opportunity to process the request. These objects are connected into a chain and the request is passed along the chain until an object handles it.

Command (Command mode): Encapsulates a request as an object, allowing you to parameterize clients with different requests; queues or logs requests, and supports optional Canceled operation.

Composite (Composition mode): Combine objects into a tree structure to represent a "part-whole" hierarchy. It enables clients to use single objects and composite objects consistently.

Decorator (Decoration mode): Dynamically add some additional responsibilities to an object. In terms of extended functionality, it is more flexible than subclassing.

Facade (Appearance mode): Provides a consistent interface for a set of interfaces in a subsystem. The Facade mode defines a high-level interface that makes this subsystem easier to use. .

Factory Method (factory pattern): Define an interface for creating objects and let subclasses decide which class to instantiate. Factory Method defers instantiation of a class to its subclasses.

Flyweight (flyweight mode): Use sharing technology to effectively support a large number of fine-grained objects.

Interpreter (Parser mode): Given a language, define a representation of its grammar, and define an interpreter that uses that representation to interpret the language sentence.

Iterator (Iterator pattern): Provides a method to sequentially access each element in an aggregate object without exposing the internal representation of the object.

Mediator (Mediator mode): Use a mediator object to encapsulate a series of object interactions. Mediators remove the need for objects to explicitly reference each other, so they are loosely coupled and can independently change their interactions.

Memento (Memo mode): Capture the internal state of an object and save this state outside the object without destroying encapsulation. This allows you to restore the object to its saved state later.

Observer (Observer pattern): Define a one-to-many dependency relationship between objects, so that when the state of an object changes, all objects that depend on it get Notifications and automatic refreshes.

Prototype (Prototype mode): Use a prototype instance to specify the type of object to be created, and create new objects by copying this prototype.

Proxy (Proxy mode): Provides a proxy for other objects to control access to this object.

Singleton (Singleton mode): Ensure that a class has only one instance and provide a global access point to access it. The singleton pattern is one of the simplest design patterns, but for Java developers, it has many flaws. In his September column, David Geary discusses the singleton pattern and how to deal with its pitfalls when faced with multi-threading, class loaders, and serialization.

State (State mode): Allows an object to change its behavior when its internal state changes. The object appears to have modified the class it belongs to.

Strategy (Strategy pattern): Define a series of algorithms, encapsulate them one by one, and make them interchangeable. This pattern allows the algorithm to change independently of the clients using it.

Template Method (Template Method Pattern): Define the skeleton of an algorithm in an operation, while deferring some steps to subclasses. Template Method allows subclasses to redefine certain specific steps of an algorithm without changing the structure of the algorithm.

Visitor (Visitor mode): Represents an operation that acts on each element in an object structure. It allows you to define new operations that act on each element without changing its class.

The above is the detailed content of Overview of PHP design patterns. For more information, please follow other related articles on the PHP Chinese website!