Core interpretation of laravel appearance mode

Time:2021-6-23

Appearance mode

Facade pattern: external communication with a subsystem must be carried out through a unified facade object, which provides a consistent interface for a group of interfaces in the subsystem. Facade pattern defines a high-level interface, which makes the subsystem easier to use. Appearance pattern, also known as facade pattern, is an object structure pattern.

What we often use in laravelRouteRedisAuthThese facades are the concrete implementation of the appearance pattern. In laravel, several appearance classes are designed, and each appearance class inherits from the unified abstract appearance class. In the abstract appearance class, the basic method of accessing the underlying subsystem through the appearance class is provided.

For new business requirements, instead of modifying the original appearance class, a new specific appearance class should be added to associate the new subsystem objects with the new specific appearance class. At the same time, the configuration file should be modified to achieve the purpose of not modifying the source code and replacing the appearance class.

The following is a simple example of appearance pattern, which does not introduce Abstract appearance classLaravel FacadesIn this article, we will see that laravel provides an abstract appearance class, so that we can easily add the appearance class of new subsystem as needed, and let the appearance class correctly proxy to its corresponding subsystem (or service).

Pattern structure

Appearance mode includes the following roles:

  • Facade appearance character
  • Subsystem roles

Core interpretation of laravel appearance mode

Code examples

<?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()
    {
        //
    }
}

pattern analysis

According to the “single responsibility principle”, dividing a system into several subsystems in software is helpful to reduce the complexity of the whole system. A common design goal is to minimize the communication and interdependence between subsystems, and one of the ways to achieve this goal is to introduce an appearance object, It provides a simple and single access for subsystem- Appearance pattern is also the embodiment of “Dimiter’s rule”. By introducing a new appearance class, the complexity of the original system can be reduced, and the coupling degree between customer class and subsystem class can be reduced- Appearance pattern requires that the communication between the outside and the inside of a subsystem is carried out through a unified appearance object. Appearance class separates the client from the internal complexity of the subsystem, so that the client only needs to deal with appearance objects, and does not need to deal with many objects inside the subsystem- The purpose of appearance pattern is to reduce the complexity of the system- Appearance mode greatly improves the convenience of the client, so that the client does not need to care about the details of the subsystem, and can call the relevant functions through the appearance role.

shortcoming

Disadvantages of appearance mode

  • It can’t restrict the customer to use the subsystem class very well. If we restrict the customer to access the subsystem class too much, it will reduce the variability and flexibility.
  • Adding a new subsystem without introducing an abstract appearance class may need to modify the appearance class or the client’s source code, which violates the “open close principle”.

Pattern extension

  • A system has multiple appearance classes

    In appearance mode, only one appearance class is needed, and there is only one instance of this appearance class. In other words, it is a singleton class. In many cases, in order to save system resources, appearance class is usually designed as singleton class. Of course, this does not mean that there can only be one appearance class in the whole 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.

  • Don’t try to add new behaviors to subsystems through appearance classes

    Don’t add new behavior to a subsystem by inheriting an appearance class, which is wrong. The purpose of appearance pattern is to provide a centralized and simplified communication channel for the subsystem, rather than adding new behaviors to the subsystem. The addition of new behaviors should be realized by modifying the original subsystem class or adding new subsystem class, not by appearance class.

  • Introduction of abstract appearance class

    The biggest disadvantage of appearance mode is that it violates the “open close principle”. When adding a new subsystem or removing a subsystem, you need to modify the appearance class. This problem can be solved to a certain extent by introducing an abstract appearance class. The client programs for the abstract appearance class. For new business requirements, instead of modifying the original appearance class, 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 the appearance class.

summary

  • In appearance mode, external communication with a subsystem must be carried out through a unified appearance object, which provides a consistent interface for a group of interfaces in the subsystem. Appearance mode defines a high-level interface, which makes the subsystem easier to use. Appearance pattern, also known as facade pattern, is an object structure pattern.
  • The appearance mode includes two roles: the appearance role is called directly by the client. In the appearance role, the functions and responsibilities of the related (one or more) subsystems can be known. It delegates all requests from the client to the corresponding subsystems and passes them to the corresponding subsystem objects for processing; In a software system, there can be one or more subsystem roles at the same time. Each subsystem can not be a separate class, but a collection of classes, which realizes the functions of subsystems.
  • Appearance pattern requires that the communication between the outside and the inside of a subsystem is carried out through a unified appearance object. Appearance class separates the client from the internal complexity of the subsystem, so that the client 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 that it shields subsystem components from customers, reduces the number of objects handled by customers and makes the subsystem easier to use. It realizes the loose coupling relationship between subsystems and customers, reduces the compilation dependency in large-scale software systems, and simplifies the migration process of the system between different platforms; The disadvantage of this method is that it can’t restrict customers to use subsystem classes, and adding new subsystems without introducing Abstract appearance classes may need to modify the appearance classes or the client’s source code, which violates the “open close principle”.
  • The application of appearance mode includes: to provide a simple interface for a complex subsystem; There is a great dependence between client program and many subsystems; In the hierarchical structure, we need to define the entrance of each layer in the system, so that there is no direct relationship between layers.

This article has been included in a series of articlesLaravel source learningWelcome to read.

Core interpretation of laravel appearance mode