在C++项目里，当业务层需要同时驱动多个独立功能模块时，调用方往往要清楚每个模块的生命周期、参数约定和错误码含义。外观设计模式（Facade）通过引入一个高层接口，把多个子系统的复杂交互隐藏起来，让外部只依赖一个稳定入口。下面以文件处理流程为例，展示如何用C++实现这一结构型模式。
一、子系统接口的设计
假设我们有三个彼此独立的子系统：压缩模块、加密模块和存储模块。它们各自负责单一职责，接口简单但组合使用时有顺序要求。如果不加封装，业务代码必须按顺序调用并判断每一步的返回值。
下面先定义三个子系统的类。它们彼此不知道对方存在，只暴露自己的处理方法。这种低耦合是外观模式能生效的前提，因为门面类后续只是协调者，而不是重新实现功能。
#include <iostream>
#include <string>
class Compresser {
public:
bool compress(const std::string& raw, std::string& out) {
out = "[compressed]" + raw;
return true;
}
};
class Encrypter {
public:
bool encrypt(const std::string& data, std::string& out) {
out = "[encrypted]" + data;
return true;
}
};
class Storage {
public:
bool save(const std::string& data, const std::string& path) {
std::cout << "save to " << path << ": " << data << std::endl;
return true;
}
};
二、外观类的实现
外观类持有子系统对象，并提供单一方法完成完整流程。调用方不再需要知道先压缩还是先加密，也不用处理中间变量。我们把流程固定为压缩、加密、存储，并在门面内统一返回成功或失败。
这种封装带来明显好处：如果将来加密算法要换实现，只需修改Encrypter或门面里的调用方式，业务层代码完全不动。同时，门面可以加入日志、重试等横切逻辑，而不污染子系统。
class FileFacade {
public:
FileFacade() : compresser(), encrypter(), storage() {}
bool process(const std::string& content, const std::string& path) {
std::string compressed;
if (!compresser.compress(content, compressed)) {
return false;
}
std::string encrypted;
if (!encrypter.encrypt(compressed, encrypted)) {
return false;
}
if (!storage.save(encrypted, path)) {
return false;
}
return true;
}
private:
Compresser compresser;
Encrypter encrypter;
Storage storage;
};
三、客户端如何使用
使用外观后，客户端代码极其简洁。它只构造门面对象并调用process，完全不必关心内部模块。这样在大型工程中，新成员也能快速上手，不会因为弄错子系统顺序写出bug。
以下示例展示主函数里的调用方式。可以看到，原本需要十几行胶水逻辑的操作，现在压缩成两行，且语义清晰：把内容处理并存到某路径。
int main() {
FileFacade facade;
bool ok = facade.process("hello world", "/tmp/out.txt");
if (ok) {
std::cout << "process done" << std::endl;
}
return 0;
}
四、与直接调用的对比
如果不使用外观模式，主函数需要依次持有三个子系统实例，并手动传递中间结果。一旦顺序写反（比如先加密后压缩），可能导致存储格式不兼容。下表列出两种写法差异。
| 维度 | 直接调用子系统 | 使用外观模式 |
|---|---|---|
| 调用方认知负担 | 高，需了解全部接口 | 低，仅知门面方法 |
| 修改子系统影响 | 业务代码多处改动 | 仅改门面内部 |
| 错误分支处理 | 分散在业务层 | 集中在门面 |
从表中能看出，外观模式以极小的类膨胀代价，换来了可维护性的提升。它尤其适合那些子系统数量多、但对外场景固定的模块群。
五、注意事项与扩展
外观类不应包含业务逻辑，否则会演变成上帝类。正确做法是只做编排与异常收敛。若子系统本身也需要被高级客户直接使用，可保留原接口，外观只是可选入口。
在C++里，还可以通过智能指针管理子系统生命周期，或把门面做成单例以避免重复构造。但若子系统无状态，直接栈对象成员也更安全。合理运用外观模式，能让结构型设计真正降低系统熵值。
C++外观设计模式facade_pattern修改时间：2026-08-05 18:48:27