如何优化PHP项目的底层架构？应用外观模式隐藏底层繁琐的第三方库调用-php教程-PHP中文网

外观模式是为复杂子系统提供统一简化接口的结构型设计模式，用于解耦客户端与子系统、降低依赖、提升易用性，典型应用于多子系统协作、遗留系统集成及分层架构入口等场景。

如何优化php项目的底层架构？应用外观模式隐藏底层繁琐的第三方库调用

外观模式不是“加一层壳就完事”，它解决的是第三方库调用中真实存在的耦合、重复初始化、错误传播和测试困难问题。直接在业务逻辑里 new GoogleClient() 或硬编码 file_get_contents('https://api.example.com/...')，迟早会拖垮维护节奏。

什么时候该用 Facade 而不是直接 new 一个客户端？

当出现以下任意一种情况时，Facade 就不是可选项，而是止损点：

同一组 API 调用在多个 Controller / Service 中重复出现（比如每次都要手动构造 token、设置 header、解析 JSON、处理 401/429）
第三方 SDK 的初始化成本高（如 Google\Client 构造时加载大量配置、验证证书、连接 discovery service）
你发现单元测试里不得不 mock 七八个依赖，只为了测一个搜索方法
团队新人第一次改支付回调逻辑，花了半天才搞懂 $paypal->getTransaction()->getDetails()->getItems()[0]->getName() 这一长串是谁的责任

Facade 类里不能出现 new，但依赖怎么来？

外观类本身必须是无状态的，它的职责是编排，不是创建。构造函数里只接收已实例化的子系统对象，且类型必须是接口而非具体类：

class PaymentFacade
{
    public function __construct(
        private PaymentGatewayInterface $gateway,
        private LoggerInterface $logger,
        private CacheInterface $cache
    ) {}
}

如果你看到 new StripeClient() 出现在 PaymentFacade::__construct() 或任何公开方法里，说明它已经越界，该拆成工厂或交给 DI 容器处理。PHP 8.1+ 推荐用命名参数 + 构造函数属性提升，让依赖一目了然。