外观模式: 复杂系统的统一入口

外观模式（Facade Pattern）：复杂系统的"统一入口"

意图

外观模式为复杂的子系统提供一个统一的简化接口 ，隐藏系统的内部复杂性，使得客户端只需与高层接口交互即可完成功能。其核心目标是降低系统使用难度 和减少客户端与子系统的耦合。

GoF定义：提供一个统一的接口，用来访问子系统中的一群接口。外观定义了一个更高层次的接口，使得子系统更容易使用。

问题

假设你必须在代码中使用某个复杂的库或框架中的众多对象。正常情况下，你需要负责所有对象的初始化工作、管理其依赖关系并按正确的顺序执行方法等。

最终，程序中类的业务逻辑将与第三方类的实现细节紧密耦合，使得理解和维护代码的工作很难进行。

解决方案

外观模式通过以下方式解决问题：

封装复杂逻辑：外观类为包含许多活动部件的复杂子系统提供一个简单的接口。与直接调用子系统相比，外观提供的功能可能比较有限，但它却包含了客户端真正关心的功能。
统一入口：如果你的程序需要与包含几十种功能的复杂库整合，但只需使用其中非常少的功能，那么使用外观模式会非常方便。
举例：例如，上传猫咪搞笑短视频到社交媒体网站的应用可能会用到专业的视频转换库，但它只需使用一个包含 encode(filename, format)方法（以文件名与文件格式为参数进行编码的方法）的类即可。在创建这个类并将其连接到视频转换库后，你就拥有了自己的第一个外观。

现实场景类比

电话购物

当你通过电话给商店下达订单时，接线员就是该商店的所有服务和部门的外观。接线员为你提供了一个同购物系统、支付网关和各种送货服务进行互动的简单语音接口。

智能家具系统

子系统：灯光、空调、窗帘、音响等设备。
外观（Facade）：智能家居控制面板。
过程：用户点击"回家模式"按钮，面板自动依次执行开灯、调温、打开窗帘、播放音乐等操作，无需手动控制每个设备。

模式结构与 UML

角色说明：

Facade：对外提供统一接口，内部调用子系统功能。
SubsystemA/B/C：实现具体功能的模块，可独立运行。
Client：通过外观类调用功能，不直接接触子系统。

代码示例

场景：家庭影院系统（播放电影需依次打开投影仪、音响、灯光调节）。

java 复制代码

// 子系统：投影仪
class Projector {
    public void on() { System.out.println("投影仪打开"); }
    public void setInput(String source) { System.out.println("输入源设置为：" + source); }
}

// 子系统：音响
class SoundSystem {
    public void on() { System.out.println("音响打开"); }
    public void setVolume(int level) { System.out.println("音量设置为：" + level); }
}

// 子系统：灯光
class Lights {
    public void dim(int level) { System.out.println("灯光调暗至" + level + "%"); }
}

// 外观类
class HomeTheaterFacade {
    private Projector projector;
    private SoundSystem sound;
    private Lights lights;

    public HomeTheaterFacade(Projector p, SoundSystem s, Lights l) {
        this.projector = p;
        this.sound = s;
        this.lights = l;
    }

    // 统一入口：一键播放电影
    public void watchMovie(String movie) {
        lights.dim(10);
        projector.on();
        projector.setInput(movie);
        sound.on();
        sound.setVolume(20);
        System.out.println("开始播放电影：" + movie);
    }
}

// 客户端调用
public class Client {
    public static void main(String[] args) {
        HomeTheaterFacade facade = new HomeTheaterFacade(
            new Projector(), new SoundSystem(), new Lights()
        );
        facade.watchMovie("星际穿越");
    }
}

// 输出：
// 灯光调暗至10%
// 投影仪打开
// 输入源设置为：星际穿越
// 音响打开
// 音量设置为：20
// 开始播放电影：星际穿越

适合场景

简化复杂系统：如框架初始化、多步骤业务流程（支付、订单处理）。
分层架构设计：为不同层提供统一入口（如数据库访问层封装JDBC操作）。
兼容旧系统：为新客户端提供简化的接口调用遗留代码。
微服务网关：聚合多个服务调用（如订单服务调用库存、支付、物流服务）。

实现方式：实战步骤

分析子系统：识别需要封装的复杂模块和调用流程。
定义外观接口 ：明确客户端需要的高层操作（如watchMovie()）。
实现外观类 ：
- 组合子系统对象（通过构造函数或依赖注入）。
- 在接口方法中编排子系统调用顺序。
替换客户端调用：将直接调用子系统的代码改为调用外观类。
优化扩展 （可选）：
- 提供多个外观类，针对不同场景（如"游戏模式""会议模式"）。
- 使用单例模式管理外观类实例。

优缺点

优点：

降低客户端与子系统的耦合，客户端代码更简洁。
提高子系统的独立性和可维护性。
符合迪米特法则（最少知识原则）。

缺点：

外观类可能成为"上帝类"，过度集中逻辑。
若子系统接口频繁变动，外观类需同步修改，违反开闭原则。

和其他设计模式的关系

外观模式为现有对象定义了一个新接口， 适配器模式则会试图运用已有的接口。适配器通常只封装一个对象，外观通常会作用于整个对象子系统上。
当只需对客户端代码隐藏子系统创建对象的方式时，你可以使用抽象工厂模式来代替外观。
享元模式 展示了如何生成大量的小型对象，外观则展示了如何用一个对象来代表整个子系统。
外观和中介者模式的职责类似：它们都尝试在大量紧密耦合的类中组织起合作。

外观为子系统中的所有对象定义了一个简单接口，但是它不提供任何新功能。子系统本身不会意识到外观的存在。子系统中的对象可以直接进行交流。
中介者将系统中组件的沟通行为中心化。各组件只知道中介者对象，无法直接相互交流。

外观类通常可以转换为单例模式类，因为在大部分情况下一个外观对象就足够了。
外观与代理模式的相似之处在于它们都缓存了一个复杂实体并自行对其进行初始化。代理与其服务对象遵循同一接口，使得自己和服务对象可以互换，在这一点上它与外观不同。

总结

外观模式是架构设计中"化繁为简"的利器，尤其适合为复杂系统（如第三方库、遗留代码）提供友好的客户端接口。其关键在于平衡封装粒度------既不能过度简化（导致灵活性丧失），也不能过于复杂（失去封装意义）。在微服务、SDK设计和模块化开发中，外观模式是提升系统易用性的核心手段。

最后

如果文章对你有帮助，点个免费的赞鼓励一下吧！关注gzh:加瓦点灯，每天推送干货知识！