设计模式（结构型设计模式——外观模式）

设计模式（结构型设计模式——外观模式）

外观模式

基本定义

外观模式是为多个复杂的子系统提供一个一致的接口，而使这些子系统更加容易被访问的模式。
外部应用程序不用关心内部子系统的具体的细节，这样会大大降低应用程序的复杂度，提高了程序的可维护性。

模式结构

Facade: 外观角色类
SubSystem: 子系统角色

代码实现

Facade: 外观角色类

模拟：回家-> 开灯，开空调，开电视机。休息->关电视机，关空调，关灯

public class Facade {

    Light light;
    Air air;
    TV tv;

    public Facade(Light light, Air air, TV tv) {
        this.light = light;
        this.air = air;
        this.tv = tv;
    }

    public void allOpen(){
        light.open();
        air.open();
        tv.open();
    }

    public void allDown(){
        tv.down();
        air.down();
        light.down();
    }
}

SubSystem: 子系统角色

灯光

@Slf4j
public class Light {

    public void open(){
        log.info("开灯");
    };

    public void down(){
        log.info("关灯");
    }
}

空调

@Slf4j
public class Air {

    public void open(){
        log.info("打开空调");
    };

    public void down(){
        log.info("关闭空调");
    }
}

电视机

@Slf4j
public class TV {
    public void open(){
        log.info("打开电视机");
    };

    public void down(){
        log.info("关闭电视机");
    }
}

测试类

public class Test {

    public static void main(String[] args){
        Facade facade = new Facade(new Light(), new Air(), new TV());
        facade.allOpen();//print: 开灯, 打开空调，打开电视机
        facade.allDown();//print: 关闭电视机,关闭空调，关灯
    }
}

优点

1. 降低了子系统与客户端之间的耦合度，使得子系统的变化不会影响调用它的客户类。
2. 对客户屏蔽了子系统组件，减少了客户处理的对象数目，并使得子系统使用起来更加容易。
3. 降低了大型软件系统中的编译依赖性，并简化了系统在不同平台之间的移植过程。
4. 符合迪米特法则，即最少知道原则。

缺点

在不引入抽象外观类的情况下，增加新的子系统可能需要修改外观类或客户端的源代码，违背了“开闭原则”。

使用场景

当要为一个复杂子系统提供一个简单接口时可以使用外观模式。

客户程序与多个子系统之间存在很大的依赖性。引入外观类将子系统与客户以及其他子系统解耦，可以提高子系统的独立性和可移植性。

总结

外观模式的主要优点就在于减少了客户与子系统之间的关联对象，使用客户对子系统的使用变得简单了，也实现了客户与子系统之间的松耦合关系。它的缺点就在于违背了“开闭原则”。

如果需要实现一个外观模式，需要将子系统组合进外观类中，然后将工作委托给子系统执行。