设计模式 - 外观模式

本文摘自书籍《设计模式》
此系列文章GitHub地址

结构型 - 外观模式（Facade Pattern）

定义

外部与一个子系统的通信必须通过一个统一的外观对象进行，为子系统中的一组接口提供一个一致的界面，外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用，是一种对象结构型模式。

模式结构

public class Facade {
    private Light light;
    private Door door;
    public void leaveHome() {
        light.off();
        door.close();
    }

    public void arriveHome() {
        door.open();
        door.on();
    }
}

public class Light {
    public void on() {...}
    public void off() {...}
}

public class Door {
    public void open() {...}
    public void close() {...}
}

• Facade

  外观角色，客户端可以调用这个角色的方法，在外观角色中可以知道相关的子系统的功能和职责；在正常情况下，它将所有从客户端发来的请求委派到响应的子系统去，传递给相应的子系统对象处理。

• Light

  子系统角色，每个子系统可以不是一个单独的类，而是一个类的集合，它实现子系统的功能；每个子系统都可以被客户端直接调用或者被外观类调用，处理由外观类传来的请求。

优点

外观模式的优点：

• 对客户端屏蔽子系统组件，减少客户处理的对象数目并使得子系统使用起来更加容易。通过引入外观刘，客户代码将变得更加简单。
• 实现了子系统与客户之间的松耦合关系。

缺点

外观模式的缺点：

• 不能很好的限制客户使用子系统类，如果对客户访问子系统类做太多的限制则减少了可变性和灵活性。
• 在不引入抽象外观类的情况下，增加新的子系统可能需要修改外观类或客户端的源代码，违背了开闭原则。

适用环境

外观模式的适用环境：

• 需要为复杂的子系统提供一个简单接口时。
• 客户程序与多个子系统存在很大的依赖时，引入外观将子系统与客户以及其它子系统解耦。
• 在层次化结构总，可以使用外观模式定义烯烃中每一层的入口，层与层之间不直接产生联系，而通过外观类建立联系，降低层之间耦合度。

注意

应用外观模式时，不能增加额外的功能；不能返回子系统构件给客户端。