多态与外观模式配合可收敛抽象类族暴露面：外观仅依赖抽象基类接口，通过运行时多态分发具体逻辑；抽象基类定义统一契约，派生类封装实现细节，外观协调调用并隐藏策略切换。
多态和外观模式配合使用，能有效收敛庞大抽象类族的对外暴露面——不是把所有子类都列出来供调用，而是让外观类只面向抽象基类编程，通过运行时多态完成具体行为分发。核心在于：外观不依赖具体实现，只依赖统一接口；而多态确保同一外观调用能触发不同子类的实际逻辑。
明确抽象基类与多态契约
先定义一个稳定、职责清晰的抽象基类（如 PaymentProcessor），声明关键虚函数（process()、validate()），并标记为 virtual 或 = 0（纯虚）。所有具体支付方式（WechatPay、Alipay、CryptoPay）继承它并实现各自逻辑。外观类内部仅持有该抽象基类的指针或引用，不包含任何具体类型名。
- 抽象基类负责定义“能做什么”，不关心“怎么做”
- 每个派生类封装自身协议、签名、异步处理等细节，彼此隔离
- 外观类构造时可接收基类指针（支持工厂或依赖注入），避免硬编码 new 具体类型
外观类封装多态调用链
外观类（如 UnifiedPaymentFacade）提供极简方法（如 execute(const Order&)），内部按顺序调用抽象基类的多态接口：
- 先调用 validator->validate(order) —— 实际执行的是 WechatValidator 或 AlipayValidator 的重载版本
- 再调用 processor->process(order) —— 根据 runtime 类型自动路由到对应支付逻辑
- 最后统一包装响应（Success/Failure）、日志、监控埋点，对客户端完全透明
解耦初始化与策略切换
庞大抽象类族常伴随配置驱动或运行时策略选择。外观类可内建策略解析能力，例如：
- 根据 order.paymentMethod 字段，从注册表中查找对应抽象基类实例（如通过 std::map
>） - 支持运行时热替换（如灰度期间将部分流量导向新 CryptoPay 实现，无需改外观接口）
- 若需默认行为，外观可自带 fallback 实例（如 DefaultNullProcessor），避免空指针风险
避免常见陷阱
这种组合易在细节上失衡：
- 不要在外观里做类型判断（如 dynamic_cast 或 if (type == "wechat")）—— 违背多态本意，也破坏开闭原则
- 抽象基类方法签名要足够通用，避免为某个子类加特例参数（如 addWechatAppId()）；差异化参数应封装进请求对象（Order 或 Context）
- 外观类本身不应成为新的抽象基类；它只是协调者，不是继承体系一员
