[Architecture-Design Mode] Appearance Mode

Posted Jun 26, 20208 min read

The appearance mode is a structural design pattern that is used very frequently. It introduces an appearance role to simplify the interaction between the client and the subsystem, provides a unified entrance for complex subsystem calls, and reduces the subsystem and client. The degree of coupling between the client and the client is very convenient.

Overview

In software development, sometimes in order to complete a more complex function, a client class needs to interact with multiple business classes, and these business classes that need to interact often appear as a whole, because more classes are involved, resulting in The code is more complicated when used. At this time, a role similar to a waiter is particularly needed, which is responsible for interacting with multiple business classes, and the client class only needs to interact with this class. The appearance mode implements this function by introducing a new Facade. The appearance class acts as a "waiter" in the software system, which provides a unified entrance for multiple business class calls, simplifying Interaction between classes. In the appearance mode, those business classes that need to interact are called Subsystems. If there is no appearance class, then each client class needs to interact with multiple subsystems, and the coupling of the system will be very large; after the introduction of the appearance class, the client class only needs to directly interact with the appearance class, the client class and the child The original complex reference relationship between systems is realized by the appearance class, thereby reducing the coupling degree of the system.

In the appearance mode, the communication between the outside and the inside of a subsystem is carried out through a unified appearance class. The appearance class separates the client class from the internal complexity of the subsystem, so that the client class only needs to deal with the appearance role. There is no need to deal with many objects inside the subsystem.

The appearance mode is defined as follows:

Appearance mode:Provide a unified entrance for a group of interfaces in the subsystem. The appearance mode defines a high-level interface that makes this subsystem easier to use.

Appearance mode is also called facade mode, it is an object structure mode. The appearance mode is a concrete realization of Dimit's law. By introducing a new appearance role, the complexity of the original system can be reduced, and at the same time, the coupling between the client class and the subsystem can be reduced.

The appearance mode does not have a general description of the class diagram. The class diagram shown below can be used as a structural diagram to describe the appearance mode:

1354636733_5965.jpg

The appearance mode includes the following two characters:

  1. Facade(appearance role):You can call its methods on the client, you can know the functions and responsibilities of the related subsystem(s) in the appearance role; under normal circumstances, it will all from the client The request sent is delegated to the corresponding subsystem and passed to the corresponding subsystem object for processing.
  2. _SubSystem(subsystem role) _:There can be one or more subsystem roles in the software system, each subsystem may not be a separate class, but a collection of classes, which implement the functions of the subsystem; each The subsystem can be called directly by the client or by the appearance role. It handles the requests passed by the appearance class; the subsystem does not know the existence of the appearance. For the subsystem, the appearance role is just another client. .

After the appearance mode is introduced, it is very convenient to add a new subsystem or remove a subsystem. The client class does not need to be modified(or rarely modified), and only needs to add or remove the reference to the subsystem in the appearance class. From this point of view, the appearance mode does not conform to the principle of opening and closing to some extent, and adding a new subsystem requires certain modifications to the original system, although this modification is not a heavy workload.

The subsystem referred to in the appearance mode is a broad concept. It can be a class, a functional module, a component of the system, or a complete system. Subsystem classes are usually business classes that implement specific and independent business functions. The typical code is as follows:

class SubSystemA
{
    public function MethodA()
    {
        //Business implementation code
    }
}

class SubSystemB
{
    public function MethodB()
    {
        //Business implementation code
    }
}

class SubSystemC
{
    public function MethodC()
    {
        //Business implementation code
    }
}

After the appearance class is introduced, the interaction with the subsystem business class is unified by the appearance class. The following code usually exists in the appearance class:

class Facade
{
    private $obj1;
    private $obj2;
    private $obj3;

    public function __construct()
    {
        $this->obj1 = new SubSystemA();
        $this->obj2 = new SubSystemB();
        $this->obj3 = new SubSystemC();
    }

    public function Method()
    {
        $this->obj1->MethodA();
        $this->obj2->MethodB();
        $this->obj3->MethodC();
    }
}

Since the reference to the subsystem object is maintained in the appearance class, the client can indirectly call the business method of the subsystem object through the appearance class without directly interacting with the subsystem object.

Case

A software company wants to develop a file encryption module that can be applied to multiple software. This module can encrypt the data in the file and store the encrypted data in a new file. The specific process includes three parts, respectively It is to read the source file, encrypt, and save the encrypted file. Among them, reading the file and saving the file are realized by using a stream, and the encryption operation is realized by a modular operation. These three operations are relatively independent. In order to achieve independent reuse of code and make the design more in line with the principle of single responsibility, the business code of these three operations is encapsulated in three different classes.

The file encryption module is now designed in appearance mode.

Through analysis, the structure diagram of this example is shown in the figure:

1354688525_6684.jpg

EncryptFacade acts as an appearance class, and FileReader, CipherMachine, and FileWriter act as subsystem classes. The sample code is as follows:

<?php

class FileReader
{
    public function Read(string $fileNameSrc):string
    {
        return file_get_contents($fileNameSrc);
    }
}

class CipherMachine
{
    public function Encrypt(string $plainText):string
    {
        return openssl_encrypt($plainText,'DES-ECB', '123456');
    }
}

class FileWriter
{
    public function Write(string $encryptStr, string $fileNameDes)
    {
        file_put_contents($fileNameDes, $encryptStr);
    }
}


class EncryptFacade
{
    //Maintain references to other objects
    private $reader;
    private $cipher;
    private $writer;

    public function __construct()
    {
        $this->reader = new FileReader();
        $this->cipher = new CipherMachine();
        $this->writer = new FileWriter();
    }

    //Call business methods of other objects
    public function FileEncrypt(string $fileNameSrc, string $fileNameDes)
    {
        $plainStr = $this->reader->Read($fileNameSrc);
        $encryptStr = $this->cipher->Encrypt($plainStr);
        $this->writer->Write($encryptStr, $fileNameDes);
    }
}

Abstract appearance class

In the standard appearance pattern structure diagram, if you need to add, delete, or replace the subsystem class that interacts with the appearance class, you must modify the appearance class or the source code of the client, which will violate the opening and closing principle, so you can introduce an abstract appearance class to To improve the system can solve this problem to a certain extent. After introducing the abstract appearance class, the client can program the abstract appearance class. For new business requirements, there is no need to modify the original appearance class, and a new concrete appearance class is added correspondingly, and the new concrete appearance class is associated with the new At the same time, by modifying the configuration file to achieve the purpose of not modifying any source code and replacing the appearance class.

If an encryption class needs to be replaced in the application file "File Encryption Module", the original encryption class CipherMachine is no longer used, but the new encryption class NewCipherMachine. If you do not add a new appearance class, you can only change the encryption class by modifying the source code of the original appearance class EncryptFacade, changing the original reference to the CipherMachine type object to the NewCipherMachine type object, which violates the open Closed principle, so you need to change the reference to the subsystem object by adding a new appearance class.

If you add a new appearance class NewEncryptFacade to interact with the FileReader class, FileWriter class and the newly added NewCipherMachine class, although the original system library does not need to be modified, but because the client code was originally programmed for the EncryptFacade class, it is now necessary Change to NewEncryptFacade class, so the client source code needs to be modified.

How to use the new appearance class without modifying the client code? One solution is to introduce an abstract appearance class. The client programs the abstract appearance class, and then determines the specific appearance class at runtime. When replacing the specific appearance class, only the configuration file needs to be modified, and the source code does not need to be modified, which conforms to the principle of opening and closing.

to sum up

Appearance mode is a very frequently used design mode. It introduces an appearance role to simplify the interaction between the client and the subsystem, provides a unified entrance for complex subsystem calls, and enables the coupling of the subsystem and the client The degree is reduced, and the client call is very convenient.

The appearance mode does not add any new functions to the system, it simply simplifies the calling interface. You can find the appearance mode application in almost all software. For example, most B/S systems have a home page or navigation page. Most C/S systems provide menus or toolbars. Here, the home page and navigation The page is the appearance role of the B/S system, and the menu and toolbar are the appearance roles of the C/S system. Through them, users can quickly access the subsystem, reducing the complexity of the system. All scenarios involving interaction with multiple business objects can be considered for reconstruction using the appearance mode.

main advantage
  1. It shields the subsystem components from the client, reduces the number of objects that the client needs to process, and makes the subsystem easier to use. By introducing the appearance mode, the client code will become very simple, and there are few objects associated with it.
  2. It realizes the loose coupling relationship between the subsystem and the client, which makes the change of the subsystem not affect the client that calls it, and only needs to adjust the appearance class.
  3. The modification of one subsystem has no effect on other subsystems, and the internal changes of the subsystem will not affect the appearance objects.
Main disadvantages
  1. The client cannot directly use the subsystem class directly. If too many restrictions are imposed on the client to access the subsystem class, the variability and flexibility are reduced.
  2. If the design is improper, adding a new subsystem may require modifying the source code of the appearance class, which violates the principle of opening and closing.
Applicable scene
  1. Appearance mode can be used when you want to provide a simple entry point for accessing a series of complex subsystems.
  2. There is a great dependency between the client program and multiple subsystems. The introduction of the appearance class can decouple the subsystem from the client, thereby improving the independence and portability of the subsystem.
  3. In the hierarchical structure, you can use the appearance mode to define the entrance of each layer in the system. There is no direct connection between the layers, but the connection is established through the appearance class to reduce the coupling between the layers.