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

In short, it hides the complexity of the system and provides the client with an interface to access the system, so that the client can use the system more easily.

In this mode, there are generally three roles.

1. Facade role: the core of appearance mode. It is called by the customer role, and it is familiar with the functions of the subsystem. According to the needs of the customer's role, several combinations of functions are reserved internally. (the customer calls and calls the subsystem function at the same time)
2. Subsystem role: it realizes the functions of the subsystem. It is unknown to the customer role and Facade. It can interact with each other within the system, or it can be called by the interface for the outside world. (realize specific functions)
3. Customer role: complete the function to be realized by calling Facede (calling facade role).

=========================================================================

Let's simulate the scene of a little love student's integrated control of MI family:

Let's assume that there are three meters of home equipment, fans, lights and TV, that is, facade roles:

Fan:

package FacadePattern.MiHomeProducts;

/**
 * @author Zeyu Wan
 * @version 1.0.0
 * @ClassName MiFan.java
 * @Description Millet fan
 * @createTime 2022 March 4, 2014 14:49:00
 */
public class MiFan {
    public void turnOn(){
        System.out.println("The fan is on");
    }

    public void turnOff(){
        System.out.println("The fan is off");
    }
}

electric light:

package FacadePattern.MiHomeProducts;

/**
 * @author Zeyu Wan
 * @version 1.0.0
 * @ClassName MiLight.java
 * @Description Xiaomi electric lamp
 * @createTime 2022 March 4, 2014 14:49:00
 */
public class MiLight {
    public void turnOn(){
        System.out.println("The light is on");
    }

    public void turnOff(){
        System.out.println("The lights are off");
    }
}

TV:

package FacadePattern.MiHomeProducts;

/**
 * @author Zeyu Wan
 * @version 1.0.0
 * @ClassName MiTv.java
 * @Description Mi TV
 * @createTime 2022 March 4, 2014 14:48:00
 */
public class MiTv {
    public void turnOn(){
        System.out.println("The TV is on");
    }

    public void turnOff(){
        System.out.println("The TV is off");
    }
}

If we go home to open one by one, it will be very troublesome:

Simulate the customer role to test:

package FacadePattern;

import FacadePattern.MiHomeProducts.MiFan;
import FacadePattern.MiHomeProducts.MiLight;
import FacadePattern.MiHomeProducts.MiTv;

/**
 * @author Zeyu Wan
 * @version 1.0.0
 * @ClassName FacedPatternTest.java
 * @Description FacadePatternTest
 * @createTime 2022 March 4, 2014 15:02:00
 */
public class FacadePatternTest {
    public static void main(String[] args) {
        MiFan miFan = new MiFan();
        MiTv miTv = new MiTv();
        MiLight miLight = new MiLight();

        miFan.turnOn();
        miLight.turnOn();
        miTv.turnOn();

    }
}

It can be seen that we need to create objects one by one and then execute methods. Suppose we have N devices and perform m operations on the devices, we need to create n objects and call methods m times, which is very unfriendly to the customer role.

If we use Xiaoai and integrate the functions into Xiaoai, it will be much more convenient:

Facade character Xiaoai:

package FacadePattern;

import FacadePattern.MiHomeProducts.MiFan;
import FacadePattern.MiHomeProducts.MiLight;
import FacadePattern.MiHomeProducts.MiTv;

/**
 * @author Zeyu Wan
 * @version 1.0.0
 * @ClassName MiAi.java
 * @Description Xiaoai classmate
 * @createTime 2022 March 4, 2014 14:54:00
 */
public class MiAi {
    private MiLight miLight;
    private MiTv miTv;
    private MiFan miFan;

    public MiAi(){
        miLight = new MiLight();
        miTv = new MiTv();
        miFan = new MiFan();
    }


    public void open(String common){
        if ("I'm home".equals(common)) {
            miFan.turnOn();
            miLight.turnOn();
            miTv.turnOn();
        }else {
            System.out.println("I don't know this skill yet");
        }
    }

}

We integrate the function of creating objects and calling into Xiaoai's open method. The only interface exposed to the customer role is open, so the customer role only needs to call him

Test again:

package FacadePattern;

import FacadePattern.MiHomeProducts.MiFan;
import FacadePattern.MiHomeProducts.MiLight;
import FacadePattern.MiHomeProducts.MiTv;

/**
 * @author Zeyu Wan
 * @version 1.0.0
 * @ClassName FacedPatternTest.java
 * @Description FacadePatternTest
 * @createTime 2022 March 4, 2014 15:02:00
 */
public class FacadePatternTest {
    public static void main(String[] args) {
        MiFan miFan = new MiFan();
        MiTv miTv = new MiTv();
        MiLight miLight = new MiLight();

        miFan.turnOn();
        miLight.turnOn();
        miTv.turnOn();
        System.out.println("\n+++++++Little love call++++++++\n");
        MiAi miAi = new MiAi();
        miAi.open("I'm home");
    }
}

It can be seen that when we encounter the call of a complex subsystem, we can use the appearance mode to provide an interface to reduce the complexity of users, and we can use the appearance mode to reduce the coupling between layers in the hierarchical structure.

The biggest disadvantage of appearance mode is that it violates the "opening and closing principle". When adding a new subsystem or removing a subsystem, the appearance class needs to be modified. This problem can be solved to a certain extent by introducing Abstract appearance classes. The client programs for abstract appearance classes. For new business requirements, instead of modifying the original appearance class, a new specific appearance class is added correspondingly. The new specific appearance class is associated with the new subsystem object. At the same time, the purpose of not modifying the source code and replacing the appearance class is achieved by modifying the configuration file.