第13章外观模式

课程目录第13章外观模式

外观模式：让复杂系统变得简单

说实话，我刚开始接触设计模式那会儿，对外观模式是有点不屑的。觉得它不就是把一堆乱七八糟的调用包起来嘛，有啥技术含量？直到我在一个大型交易系统里被子系统之间的耦合折磨得死去活来，才明白——外观模式，其实是架构师的入门必修课。

模式动机：为什么需要外观？

你想想看，一个复杂的系统往往由多个子系统组成。比如一个智能家居系统，有灯光控制、空调控制、安防系统、影音系统……每个子系统都有自己的接口。用户想"离家模式"，得先关灯、再关空调、再设安防、再关电视……这谁记得住？

我在项目中遇到过类似的情况。一个支付系统，对接了微信、支付宝、银联、跨境支付……每个渠道的初始化、签名、回调处理都不一样。业务方说"我就想发起一笔支付"，结果我得调十几个接口。嗯，这时候外观模式就派上用场了。

  核心动机：为复杂子系统提供一个统一的高层接口，降低客户端的使用难度和耦合度。

模式定义

外观模式（Facade Pattern）的定义其实很简单：为子系统中的一组接口提供一个一致的界面。说白了，就是给一堆复杂的操作包一层"皮"，让调用者只跟这层皮打交道。

我个人的习惯是，把外观模式理解为"前台接待员"。你找一家公司办事，不需要知道内部谁负责财务、谁负责技术、谁负责行政。你只需要跟前台说"我要办XX业务"，前台帮你搞定一切。这就是外观模式。

角色与结构

外观模式涉及三个核心角色：

角色	职责	类比
Facade（外观）	提供统一接口，封装子系统调用	前台接待员
Subsystem（子系统）	实现具体功能，不感知外观的存在	公司各部门
Client（客户端）	只与外观交互，不直接调用子系统	来访客户

这里有个关键点：子系统并不知道外观的存在。它们各自独立工作，外观只是把它们串起来。这种设计保证了子系统的可复用性——你可以在不同场景下用不同的外观来组合它们。

C++代码实现

来看一个实际例子。假设我们有一个电脑开机系统，涉及CPU、内存、硬盘、显卡等多个子系统。直接让客户端一个个调用，太痛苦了。我们用外观模式封装一下。

先定义子系统：

// 子系统：CPU
class CPU {
public:
    void freeze() { std::cout << "CPU: 冻结状态\n"; }
    void jump(long position) { std::cout << "CPU: 跳转到 " << position << "\n"; }
    void execute() { std::cout << "CPU: 执行指令\n"; }
};

// 子系统：内存
class Memory {
public:
    void load(long position, const std::string& data) {
        std::cout << "内存: 加载数据到 " << position << "\n";
    }
};

// 子系统：硬盘
class HardDrive {
public:
    std::string read(long lba, int size) {
        return "硬盘数据 (LBA: " + std::to_string(lba) + ")";
    }
};

// 子系统：显卡
class GPU {
public:
    void initialize() { std::cout << "显卡: 初始化完成\n"; }
    void display() { std::cout << "显卡: 显示画面\n"; }
};

然后定义外观类：

// 外观类：电脑
class ComputerFacade {
private:
    CPU cpu;
    Memory memory;
    HardDrive hardDrive;
    GPU gpu;

public:
    void start() {
        std::cout << "===== 电脑开机 =====" << std::endl;

        cpu.freeze();
        memory.load(0, hardDrive.read(0, 1024));
        cpu.jump(0);
        cpu.execute();
        gpu.initialize();
        gpu.display();

        std::cout << "===== 开机完成 =====" << std::endl;
    }

    void shutdown() {
        std::cout << "===== 电脑关机 =====" << std::endl;
        // 简化处理，实际需要更多步骤
        std::cout << "保存状态...\n";
        std::cout << "关闭硬件...\n";
        std::cout << "===== 关机完成 =====" << std::endl;
    }
};

客户端使用：

int main() {
    ComputerFacade computer;
    computer.start();  // 一键开机
    // ... 使用电脑 ...
    computer.shutdown();  // 一键关机
    return 0;
}

我的经验：外观模式特别适合做"一键操作"的场景。我在做智能家居项目时，把"离家模式""回家模式""睡眠模式"都封装成了外观方法。用户按一个按钮，背后可能调了十几个设备接口，但用户完全不需要知道。

子系统封装的艺术

外观模式的核心价值在于封装。但封装不是简单的"把代码堆在一起"，而是有讲究的。

我总结了几条原则：

粒度适中：外观方法不要太大，也不要太小。一个方法做一件事，但这件事可能涉及多个子系统。
不暴露子系统细节：外观的接口应该用业务语言命名，而不是技术语言。比如叫"start()"而不是"freezeCPUAndLoadMemory()"。
允许绕过外观：高级用户如果确实需要直接操作子系统，应该允许。外观不是强制约束，而是便利工具。

避坑指南：我曾经犯过一个错误——把外观类变成了"上帝类"。所有业务逻辑都塞进外观里，结果外观类越来越臃肿，最后比子系统还难维护。记住：外观是协调者，不是执行者。具体逻辑应该留在子系统里。

什么时候用外观模式？

我个人判断是否使用外观模式，主要看三点：

子系统太复杂：客户端需要了解太多子系统才能完成一个操作。
存在明显的"操作序列"：多个子系统调用有固定的顺序和组合。
需要解耦：客户端和子系统之间的依赖关系太强，想降低耦合。

举个例子。我在做微服务网关时，每个业务请求需要调用多个下游服务。如果让前端直接调，前端得知道所有服务的地址、协议、参数格式。用外观模式封装一层网关，前端只需要发一个请求，网关内部去协调各个服务。这就是外观模式在分布式系统中的应用。

  一句话总结：外观模式不是让你少写代码，而是让你的代码更好用、更易维护。它把复杂性藏起来，把简单留给别人。

嗯，外观模式就讲到这里。记住它的核心思想：复杂的东西，外面包一层简单的壳。这个思想不仅在代码里有用，在架构设计、系统集成、甚至日常工作中都很有启发。

📚 课程目录

外观模式：让复杂系统变得简单

模式动机：为什么需要外观？

模式定义

角色与结构

C++代码实现

子系统封装的艺术

什么时候用外观模式？