[design mode] Chapter 10: appearance mode, the joy of driving a small broken car

The joy of driving a small broken car

I don't know if you've ever driven or sat in such a "small broken car" and he can run, but the internal entertainment or some auxiliary equipment can be almost ignored. Although the conditions are harder, we still have to create happiness for ourselves. In summer, it's too hot to install an air conditioner first. In fact, it's a small electric fan, and then our 360 degree audio experience, In fact, it's a subwoofer. Come on, the most luxurious device comes. A screen is connected on the light shield, and a simple DVD machine can be connected. Well, although the sparrow is small, it has all five internal organs. It's like code. After all, it has functions, and the program that can run is a "good program", right? Hahaha~

(1) The bitterness of a small broken car

Get in the car, turn on my small electric fan, turn on the small stereo, and then put the DVD in place. You can start the small broken car and start. When you get out of the car, turn off the fire, turn off the DVD, stereo and electric fan in turn, and then you can go out. Although it's full of ritual feeling, because these external devices are independent one by one, I need to operate them in turn whether they are turned on or off. I'll come back and toss about this after a busy day, Don't worry about it

I really envy other people's "luxury" cars. After getting on the bus, one click fire, all supporting equipment will start automatically, cool air conditioning and dynamic music

Fantasize, can I also refit my little broken car into a "smart" look?

Now let's take a look at the transformation of our small broken car equipment with code

(2) Transform my little broken car

First, let's reproduce the original state of my DVD s, stereos and so on

Note: This is just for demonstration. In the single thread environment, we simply use the hungry man type single example. The air conditioner is also the small electric fan mentioned above. Let's call it so

/**
 * Air conditioning equipment
 */
public class AirConditioner {
    // Hungry Han style single case
    private static AirConditioner instance = new AirConditioner();

    public static AirConditioner getInstance() {
        return instance;
    }

    public void turnOn() {
        System.out.println("Turn on the air conditioner");
    }

    public void turnOff() {
        System.out.println("Turn off the air conditioner");
    }
}

This is the stereo

/**
 * hi-fi equipment
 */
public class Sound {
    // Hungry Han style single case
    private static Sound instance = new Sound();

    public static Sound getInstance() {
        return instance;
    }

    public void turnOn() {
        System.out.println("Turn on the sound");
    }

    public void turnOff() {
        System.out.println("Turn off the audio");
    }

}

This is a DVD

public class DVDPlayer {
    // Hungry Han style single case
    private static DVDPlayer instance = new DVDPlayer();

    public static DVDPlayer getInstance() {
        return instance;
    }

    public void turnOn() {
        System.out.println("open DVD");
    }

    public void turnOff() {
        System.out.println("close DVD");
    }

}

If you test it in the traditional way

public class Test {
    public static void main(String[] args) {
        // Get examples of three devices
        AirConditioner airConditioner = AirConditioner.getInstance();
        DVDPlayer dvdPlayer = DVDPlayer.getInstance();
        Sound sound = Sound.getInstance();

        System.out.println("=====Opening process=====");
        airConditioner.turnOn();
        dvdPlayer.turnOn();
        sound.turnOn();
        
        System.out.println("=====Closing process=====");
        airConditioner.turnOff();
        dvdPlayer.turnOff();
        sound.turnOff();
    }
}

test result

=====Opening process=====
Turn on the air conditioner
 open DVD
 Turn on the sound
=====Closing process=====
Turn off the air conditioner
 close DVD
 Turn off the audio

There's no problem with the effect, but it can be seen that six methods need to be implemented for the switch of just three devices. If there are more devices, if there are not only switches, but also some other operations, wouldn't it be tiring to death? Although our car is worn-out, it's too much trouble

Come on, transform!

We create a CarFade appearance class to encapsulate these details

public class CarFacade {
    private AirConditioner airConditioner;
    private DVDPlayer dvdPlayer;
    private Sound sound;

    // Get an instance in a parameterless construct
    public CarFacade() {
        this.airConditioner = AirConditioner.getInstance();
        this.dvdPlayer = DVDPlayer.getInstance();
        this.sound = Sound.getInstance();
    }
	
    // One click on
    public void turnOn() {
        airConditioner.turnOn();
        dvdPlayer.turnOn();
        sound.turnOn();
    }
	
    // One key off
    public void turnOff() {
        airConditioner.turnOff();
        dvdPlayer.turnOff();
        sound.turnOff();
    }
}

Let's see how to test it

package cn.ideal.facade;

/**
 * @ClassName: Test
 * @Author: BWH_Steven
 * @Date: 2020/11/27 11:35
 * @Version: 1.0
 */
public class Test {
    public static void main(String[] args) {
          // Get examples of three devices
        CarFacade carFacade = new CarFacade();

        System.out.println("=====Opening process=====");
        carFacade.turnOn();

        System.out.println("=====Closing process=====");
        carFacade.turnOff();
    }
}

Test results:

=====Opening process=====
Turn on the air conditioner
 open DVD
 Turn on the sound
=====Closing process=====
Turn off the air conditioner
 close DVD
 Turn off the audio

The effect is the same, no problem, but as callers, it's comfortable. We can also turn on and off these entertainment auxiliary devices with one click. In fact, it uses a simple and practical design mode - appearance mode. Let's take a look at its concept

II. Appearance mode theory

(1) Concept

Appearance mode (facade mode): it is a mode that makes these subsystems more accessible by providing a consistent interface for multiple complex subsystems

It is also easy to understand the above examples. Air conditioning, impression and DVD are complex subsystems, and we provide a consistent CarFacade for them. We avoid accessing the specific details of a subsystem and only need to implement it. This CarFacade provides us with a method for external, which actually achieves the effect of encapsulation and simplification

There are other examples. For example, when we want to apply for a registered permanent residence or register a company in our life, we often need to go back and forth between multiple departments, open certificates and go through formalities everywhere. However, if there is a comprehensive department that uniformly handles the corresponding business, there is no need for users to go back and forth. We just need to submit the specified materials according to the external window of this comprehensive part and wait for it to help you

Back to the code, in fact, we have intentionally or unintentionally used the appearance mode in our usual development. For example, in high-level modules, we want to call multiple relatively complex subsystems. In order to reduce the number of interfaces, we generally create a new class and call it to encapsulate, so that the final caller can call the functions of these subsystems more concisely and easily

(2) Structure

Still analyze its role:

  • Facade role: provide a common interface or consistent interface for multiple subsystems to make these subsystems easier to use
  • Sub System role: realize some functions of the system. In fact, they are the content we really want to access. Customers can access it through appearance role
  • Client role: access the functions of each subsystem through one appearance role

(3) Advantages and disadvantages

(1) Advantages

  • It simplifies the calling process: you only need to access the external interface given by the appearance mode to complete the call
  • Better encapsulation: using appearance mode, subsystem functions and specific details are hidden, and the encapsulation is better
  • It reduces the dependency of the subsystem and the interaction with the caller
  • According to Dimitri's law

(2) Shortcomings

  • Can not avoid the expansion risk well: when the subsystem is expanded within the system, it is easy to produce risks
  • Violation of the opening and closing principle: when expanding the subsystem, you may need to modify the appearance class, which will violate the opening and closing principle

(4) When to use appearance mode

(1) Complex hierarchy

At the initial stage of development, we will consciously use some common architecture methods, such as MVC. When the hierarchy and business are very complex, we need to consider creating an appearance object as an entry at each level, so as to provide some simple interfaces for complex subsystems

(2) There are many and complex subsystems

If we constantly update and expand some functions, there will be many small but indispensable classes, or some very complex systems, such as many classes. At this time, we can consider creating a Facade class to simplify the interface and reduce the dependence between them

(3) Call old system functions

Some old systems have almost no value of maintenance and expansion. Yes, but some of them involve a lot of core functions. We don't have enough energy and cost to refactor in the new system. We can only design a Facade class to interact with the code of the old and new systems

Tags: Design Pattern

Posted by JovanLo on Mon, 02 May 2022 06:19:49 +0300