An in-depth analysis of appearance patterns in the Laravel framework-Laravel-php.cn

laravelThe facade pattern (Facade Pattern) in the framework means that external communication with a subsystem must be carried out through a unified facade object to provide a consistent interface for a set of interfaces in the subsystem. The facade pattern defines a high-level interface that makes this subsystem easier to use. Appearance mode is also called facade mode, which is an object structure mode.

The Facades Route, Redis, and Auth that we commonly use in Laravel are the specific implementations of the appearance pattern. Many of them are designed in Laravel. Each appearance class inherits from a unified abstract appearance class. The abstract appearance class provides basic methods for accessing the subsystem behind it through the appearance class.

For new business needs, do not modify the original appearance class, but add a new specific appearance class. The new specific appearance class is associated with the new subsystem object, and at the same time, it is achieved by modifying the configuration file. The purpose is not to modify the source code and replace the appearance class.

The following is an example of a simple appearance pattern, which does not introduce an abstract appearance class. In the article introducing Laravel Facade, we will see that Laravel provides an abstract appearance class so that we can easily customize it according to our needs. Add the appearance class of the new subsystem, and enable the appearance class to correctly proxy to its corresponding subsystem (or service).

Mode structure

The appearance mode contains the following roles:

Facade appearance role
SubSystem Subsystem Role

An in-depth analysis of appearance patterns in the Laravel framework

#Code Example

<?php class Client
{
    public function main()
    {
        (new Facade)->operation();
    }
}

class Facade
{
    private $systemA;
    private $systemB;
    
    public function __construct()
    {
        $this->systemA = new SystemA;
        $this->systemB = new SystemB;
    }
    
    public function operation()
    {
        $this->systemA->operationA();
        $this->systemB->operationB();
    }
}

class SystemA
{
    public function operationA()
    {
        //
    }
}

class SystemB
{
    public function operationB()
    {
        //
    }
}

Copy after login

Pattern Analysis

According to the "single responsibility principle", dividing a system into several subsystems in software is beneficial to reducing the complexity of the entire system. A common design goal is to enable communication and interdependence between subsystems Achieve minimum, and one way to achieve this goal is to introduce a facade object, which provides a simple and single entry point for access to the subsystem. -Appearance mode is also a manifestation of "Demeter's Law". By introducing a new appearance class, the complexity of the original system can be reduced, and the coupling between the client class and the subsystem class can be reduced. - The appearance pattern requires that communication between the outside of a subsystem and its interior is carried out through a unified appearance object. The appearance class separates the client from the internal complexity of the subsystem, so that the client only needs to deal with the appearance object without Work with many objects within the subsystem. -The purpose of appearance mode is to reduce the complexity of the system. -The appearance mode greatly improves the convenience of client use, so that the client does not need to care about the working details of the subsystem and can call related functions through the appearance role.

Disadvantages

Disadvantages of the appearance mode

It cannot restrict customers' use of subsystem classes very well. If you do too much for customers to access subsystem classes Limitations reduce variability and flexibility.
Without introducing an abstract appearance class, adding a new subsystem may require modifying the source code of the appearance class or client, which violates the "opening and closing principle".

Pattern extension

A system has multiple appearance classes
In appearance mode, usually only one appearance class is needed , and this appearance class has only one instance, in other words it is a singleton class. In many cases, in order to save system resources, appearance classes are generally designed as singleton classes. Of course, this does not mean that there can only be one appearance class in the entire system. Multiple appearance classes can be designed in a system. Each appearance class is responsible for interacting with some specific subsystems and providing corresponding business functions to users.
Do not try to add new behaviors to the subsystem through appearance classes.
Do not add new behaviors to the subsystem by inheriting an appearance class. This approach is wrong. . The purpose of the appearance pattern is to provide a centralized and simplified communication channel for subsystems, rather than adding new behaviors to the subsystem. The addition of new behaviors should be achieved by modifying the original subsystem class or adding a new subsystem class. , cannot be implemented through appearance classes.
Introduction of abstract appearance classes
The biggest disadvantage of appearance mode is that it violates the "opening and closing principle", which is required when adding new subsystems or removing subsystems Modifying the appearance class can solve this problem to a certain extent by introducing abstract appearance classes, and the client programs for the abstract appearance classes. For new business needs, the original appearance class is not modified, but a new specific appearance class is added. The new specific appearance class is associated with the new subsystem object. At the same time, the configuration file is modified to achieve the purpose of not modifying the source code and replacing it. Appearance class purpose.

Summary

In appearance mode, external communication with a subsystem must be carried out through a unified appearance object, which is a group of subsystems. The interface provides a consistent interface, and the facade pattern defines a high-level interface that makes this subsystem easier to use. Appearance mode is also called facade mode, which is an object structure mode.
The appearance mode contains two roles: the appearance role is a role that is directly called on the client. In the appearance role, you can know the functions and responsibilities of the relevant (one or more) subsystems. , it delegates all requests from the client to the corresponding subsystem and passes them to the corresponding subsystem object for processing; there can be one or more subsystem roles in the software system at the same time, and each subsystem may not be a separate A class, but a collection of classes that implements the functions of a subsystem.
The appearance pattern requires that communication between the outside of a subsystem and its interior is carried out through a unified appearance object. The appearance class separates the client from the internal complexity of the subsystem, making the client The end only needs to deal with appearance objects, and does not need to deal with many objects inside the subsystem.
The main advantage of appearance mode is to shield subsystem components from customers, reduce the number of objects processed by customers and make the subsystem easier to use. It realizes the communication between subsystem and customers. It loosely couples the relationship, reduces compilation dependencies in large software systems, and simplifies the transplantation process of systems between different platforms; its disadvantage is that it cannot well restrict customers' use of subsystem classes, and it does not introduce abstract appearance classes. In some cases, adding a new subsystem may require modifying the appearance class or client source code, violating the "open-close principle".
Applicable situations of the appearance pattern include: providing a simple interface for a complex subsystem; there is a large dependency between the client program and multiple subsystems; in a hierarchical structure, The entrance to each layer in the system needs to be defined so that there is no direct connection between layers.

The above is the entire content of this article, please pay attention to laravel framework introductory tutorial for more information.