Follow the public account JavaStrom to learn more

Facade Pattern: External communication with a subsystem must be through a unified Facade object that provides a consistent interface for a set of interfaces in the subsystem. The Facade Pattern defines a high-level interface through which the subsystem is made easier to use. Also known as the facade pattern, belongs to the object structural pattern.

role

The appearance mode mainly contains the following roles:

  • Facade: A unified high-level interface through which client requests are delegated to different subsystems.
  • SubSystem: Equivalent to parts, composed of parts to complete a single function. Each function is a subsystem.

Scenario analysis

This is one of the most common development patterns we use, and we write code using this pattern every day, even if we don’t realize it.

According to the “single responsibility principle”, in the heart of the software system is divided into several subsystems is beneficial to reduce the complexity of the system, a common design goal is to make the communication between the subsystems and minimum mutual dependence, and one of the ways to achieve this goal is to introduce an object appearance, it as a subsystem of access provides a simple and single entry.

The facade pattern requires that the communication between the exterior and interior of a subsystem is carried out through a unified facade object. The facade class separates the client from the internal complexity of the subsystem, so that the client only needs to deal with the facade object, but does not need to deal with many objects inside the subsystem. Facade mode is designed to reduce the complexity of the system. The facade mode greatly improves the convenience of using the client, making it unnecessary for the client to care about the details of the subsystem, and can invoke related functions through the facade role.

  • For example, to buy things through the online mall: judge whether there is stock – create an order – pay deduction – create logistics – notification message – add user points. One of our order operations may involve many calls between systems, while externally we just use an order interface.
  • Go to teahouse to drink tea with oneself make tea to drink: go to teahouse to say directly like tea what tea all had, still have beauty pour tea. And their own tea to boil water, wash tea set, warm tea set, pour tea, wash tea set.
  • Such as computer on and off. Start CPU, memory, disk… with a button. Users don’t have to deal with every piece of hardware.

The code field

Now let’s simulate switching the machine through appearance mode.

Our CPU, Disk, and Memory are actually our different services, so we first define the business functions of each subsystem.

Define our subsystem roles

public class CPU {
    public void startup(a){
        System.out.println("cpu startup!");
    }

    public void shutdown(a){
        System.out.println("cpu shutdown!"); }}public class Disk {

    public void startup(a){
        System.out.println("disk startup!");
    }

    public void shutdown(a){
        System.out.println("disk shutdown!"); }}public class Memory {

    public void startup(a){
        System.out.println("memory startup!");
    }

    public void shutdown(a){
        System.out.println("memory shutdown!"); }}Copy the code

Define appearance roles

/** * Created by unique on 2017/5/14. */
public class ComputerFacade {

    private CPU cpu = new CPU();

    private Memory memory = new Memory();

    private Disk disk = new Disk();

    private ComputerFacade(a) {}// Singleton mode
    private static class Holder {
        private static ComputerFacade instance = new ComputerFacade();
    }

    public static ComputerFacade getInstance(a) {
        return Holder.instance;
    }

    /** * The user does not need to deal with each hardware, just like a switch to handle */
    public void startup(a){
        System.out.println("start the computer!");
        cpu.startup();
        memory.startup();
        disk.startup();
        System.out.println("start computer finished!");
    }

    public void shutdown(a){
        System.out.println("begin to close the computer!");
        cpu.shutdown();
        memory.shutdown();
        disk.shutdown();
        System.out.println("computer closed!"); }}Copy the code

This way we can boot up through appearance classes without having to deal with every piece of hardware.

Define our client class to call power-on and power-off.

public class UserClient {

    public static void main(String[] args) {
        ComputerFacade facade = ComputerFacade.getInstance();
        facade.startup();
        System.out.println("Time is up, you can turn off....."); facade.shutdown(); }}Copy the code

We can see the print result, with tedious details achieved by just calling a method.

start the computer! cpu startup! memory startup! disk startup! start computer finished! Time is up, you can shut down..... begin to close the computer! cpu shutdown! memory shutdown! disk shutdown! computer closed!Copy the code

disadvantages

  • You can’t limit customer access to subsystem classes very well, and limiting customer access to subsystem classes too much reduces variability and flexibility.
  • Adding a new subsystem without introducing abstract facade classes may require modifying the facade class or client source code, violating the “open closed principle.”

advantages

  • Shielding subsystem components from the customer reduces the number of objects the customer processes and makes the subsystem easier to use. By introducing the facade pattern, the client code becomes simple and has few objects associated with it.
  • The loose coupling between the subsystem and the customer is realized, so that the component changes of the subsystem do not affect the customer class that calls it, and only need to adjust the appearance class.
  • It simply provides a unified portal to access subsystems without affecting users’ ability to use subsystem classes directly.

Don’t you care about it objectively? Long press the QR code to follow the public account JavaStorm