外观模式通过统一高层接口简化复杂子系统交互，C++中关键在于封装调用逻辑而非单纯封装类；外观类聚合子系统对象（推荐智能指针或直接成员），不继承、不暴露细节，仅提供业务方法，如HomeTheaterFacade封装影院设备启停流程。
外观模式（Facade Pattern）的核心是为一组复杂的子系统接口提供一个统一、简化的高层接口，让客户端无需了解内部细节就能完成常见操作。在 C++ 中实现它，关键不是“封装类”，而是“封装交互逻辑”——把原本需要调用多个类、多次协调的流程，收拢到一个外观类中。
定义外观类，聚合子系统对象
外观类不继承子系统，而是持有它们的引用或指针（推荐智能指针或直接对象成员，避免裸指针）。它不暴露子系统细节，只提供有意义的业务方法。
例如，模拟一个「家庭影院控制系统」：包含投影仪、音响、灯光、幕布、播放器等多个设备，用户每次看电影要手动开关七八个设备。外观类 HomeTheaterFacade 就把这一整套流程封装起来：
class Projector { public: void on() { cout << "Projector is ON\n"; } void off() { cout << "Projector is OFF\n"; } };
class SoundSystem { public: void on() { cout << "SoundSystem is ON\n"; } void setVolume(int v) { cout << "Volume set to " << v << "\n"; } void off() { cout << "SoundSystem is OFF\n"; } };
class Lights { public: void dim(int level) { cout << "Lights dimmed to " << level << "%\n"; } void off() { cout << "Lights OFF\n"; } };
class Screen { public: void down() { cout << "Screen is DOWN\n"; } void up() { cout << "Screen is UP\n"; } };
class DVDPlayer { public: void on() { cout << "DVDPlayer is ON\n"; } void play(const string& movie) { cout << "Playing '" << movie << "'\n"; } void stop() { cout << "DVDPlayer stopped\n"; } void off() { cout << "DVDPlayer is OFF\n"; } };
class HomeTheaterFacade {
private:
Projector projector;
SoundSystem sound;
Lights lights;
Screen screen;
DVDPlayer player;
public:
void watchMovie(const string& movie) {
cout << "\n--- Starting movie night ---\n";
projector.on();
sound.on();
sound.setVolume(8);
lights.dim(10);
screen.down();
player.on();
player.play(movie);
}
void endMovie() {
cout << "\n--- Shutting down theater ---\n";
player.stop();
player.off();
screen.up();
lights.off();
sound.off();
projector.off();
}};
客户端只依赖外观，不接触子系统
调用方只需创建外观对象，调用高层语义方法，完全不用知道背后调了哪些类、顺序如何、参数怎么配：
int main() {
HomeTheaterFacade theater;
theater.watchMovie("Inception");
theater.endMovie();
return 0;
}
输出清晰反映流程：
--- Starting movie night ---
Projector is ON
SoundSystem is ON
Volume set to 8
Lights dimmed to 10%
Screen is DOWN
DVDPlayer is ON
Playing 'Inception'
支持灵活
扩展与解耦
扩展与解耦如果后续增加「空调」或「智能窗帘」，只需在外观类中添加对应成员和逻辑，对外接口（watchMovie）可保持不变；子系统类自身也可独立演进，只要接口契约稳定，外观类就无需大改。
必要时还可引入策略或配置，比如支持不同观影模式（“标准”、“IMAX”、“静音”），让外观类根据参数选择不同的子系统组合行为，而不是把所有逻辑硬编码死。
注意点：避免外观变成“上帝类”
外观不是万能胶水，它应聚焦于「高频、成组、有业务意义」的交互场景。不要把所有子系统方法都简单转发一遍，那只是包装器，不是外观模式。
- 每个外观方法应解决一个具体用户目标（如“开始观影”“暂停会议”“启动备份”）
- 子系统之间若存在强依赖（如必须先开电源再初始化设备），应在外观中显式处理顺序和错误回滚
- 如需支持部分功能定制（如自定义音量），可通过参数或设置函数暴露有限可控选项，而非开放全部子系统接口
