外观模式通过封装门面类统一协调多个底层类，解决调用路径混乱和依赖暴露问题；OrderFacade应聚焦稳定高频的内聚操作（如创建可支付订单），避免误用为工具类、嵌入业务规则或过度分层。
外观模式在 PHP 中不是靠某个函数或扩展实现的，而是通过手动封装一个“门面类”来统一协调多个底层类的协作——它解决的从来不是语法问题，而是调用路径混乱、依赖暴露过多的问题。
为什么不能直接 new 多个类来组合功能？
当你需要同时调用 PaymentGateway、InventoryService 和 NotificationSender 完成一次下单操作时，每个调用都可能涉及初始化、参数校验、异常处理和顺序依赖。硬编码这些逻辑会导致：
- 控制器或服务类里堆砌大量胶水代码
- 同一组协作逻辑在多处重复（比如创建订单 + 扣库存 + 发通知）
- 某底层类接口变更（如
InventoryService::decrease()改成reserve()）会波及所有调用点
外观类就是把这些耦合点收口，让外部只跟一个类打交道。
如何设计一个实用的 OrderFacade 类？
关键不是“写个壳”，而是识别出稳定、高频、有内聚语义的操作单元。比如“创建可支付订单”就是一个典型场景，它内部要：
立即学习“PHP免费学习笔记（深入）”；
- 校验商品库存（调用
InventoryService） - 生成订单记录（调用
OrderRepository） - 预占库存（调用
InventoryService） - 返回含支付链接的结构化数据（不暴露
PaymentGateway的generateUrl()细节）
示例代码片段：
class OrderFacade
{
private InventoryService $inventory;
private OrderRepository $orderRepo;
private PaymentGateway $payment;
<pre class="brush:php;toolbar:false;">public function __construct(
InventoryService $inventory,
OrderRepository $orderRepo,
PaymentGateway $payment
) {
$this->inventory = $inventory;
$this->orderRepo = $orderRepo;
$this->payment = $payment;
}
public function createPayableOrder(array $items): array
{
// 1. 库存预检
foreach ($items as $item) {
if (!$this->inventory->hasEnough($item['sku'], $item['qty'])) {
throw new OutOfStockException("SKU {$item['sku']} out of stock");
}
}
// 2. 创建订单（未支付状态）
$order = $this->orderRepo->create([
'items' => $items,
'status' => 'pending_payment'
]);
// 3. 预占库存（非扣减，防超卖）
$this->inventory->reserve($order->id, $items);
// 4. 返回统一结构，隐藏支付网关细节
return [
'order_id' => $order->id,
'pay_url' => $this->payment->generateUrl($order->id, $order->total),
'expires_at' => time() + 15 * 60,
];
}}
Facade 类容易被误用的三个地方
外观模式失效往往不是因为没写，而是用错了位置或方式：
- 把
OrderFacade做成静态工具类（如OrderFacade::createPayableOrder()），导致无法 mock 依赖，测试困难 - 在 Facade 里塞业务规则（比如“满 200 减 20”），这属于领域逻辑，应该下沉到
OrderService或PromotionEngine，Facade 只负责编排 - 给每个底层类配一个 Facade（
PaymentFacade、InventoryFacade），反而增加了间接层——Facade 是为跨组件协作而生，不是为单类封装
什么时候该考虑引入 Facade？
当你的调用方（比如控制器）出现以下任一情况时，就该动手了：
- 一行
new后紧跟三四个方法调用，且每次调用都要传相似参数 - 同一个流程在多个控制器里重复出现（如“下单→发短信→推消息→更新用户积分”）
- 团队新人总问“我要发通知，得先查哪个对象？再调谁？顺序错了吗？”
Facade 不是银弹，它不减少复杂度，只是把复杂度从调用方转移到一个明确归属的类里——这个转移是否值得，取决于协作边界是否清晰、变化频率是否一致。
