设计模式之外观模式

概念

外观模式（Facade），为子系统中的一组接口提供一个一致的界面，此模式定义了一个高层接口，这个接口使得这一子系统更加容易使用

优点

• 将客户端与子系统组件隔离开来，使其更易于使用并减少依赖关系
• 促进子系统与其客户端之间的弱耦合
• 简化复杂系统的API

何时使用外观模式

1. 在设计初期阶段，应该要有意识的将不同的两个层分离。比如经典的三层架构，就需要考虑在数据访问层和业务逻辑层、业务逻辑层和表示层的层与层之间建立外观Facade，这样可以为复杂的子系统提供一个简单的接口，使得耦合大大降低
2. 在开发阶段，子系统往往因为不断的重构演化而变得越来越复杂，大多数的模式使用时也都会产生很多很小的类，这本是好事，但也给外部调用它们的用户程序带来了使用上的困难，增加外观Facade可以提供一个简单的接口，减少它们之间的依赖
3. 在维护一个遗留的大型系统时，可能这个系统已经非常难以维护和扩展了，但因为它包含非常重要的功能，新的需求开发必须要依赖于它。此时用外观模式Facade也是非常合适的。你可以为新系统开发一个外观Facade类，来提供设计粗糙或高度复杂的遗留代码的比较清晰简单的接口，让新系统与Facade对象交互，Facade与遗留代码交互所有复杂的工作

注意事项

如果没有正确实现，facade可能成为与应用程序的所有类耦合的对象（上帝对象）

什么是 God Object（上帝对象）

• 上帝对象是一个过于庞大、知道太多、做太多事情的对象
• 它往往与系统中的大多数类都有耦合关系
• 违反了单一职责原则，难以维护和测试

Facade 变成 God Object 的原因

1. 职责过度扩张

// 糟糕的实现
class BadFacade {
    private ServiceA serviceA;
    private ServiceB serviceB;
    private ServiceC serviceC;
    // ... 更多服务

    public void doEverything() {
        // 处理所有业务逻辑
        serviceA.doSomething();
        serviceB.process();
        serviceC.handle();
        // ... 大量业务逻辑
    }
}

2.过度集中的控制

class GoodFacade {
    private SubsystemA subsystemA;
    private SubsystemB subsystemB;

    // 只提供必要的高层接口
    public void operation() {
        subsystemA.operationA();
        subsystemB.operationB();
    }
}

如何避免 Facade 变成 God Object

1. 保持单一职责

• Facade 应该只负责协调和委派
• 不要在 Facade 中实现具体的业务逻辑

2. 合理分层

• 可以使用多个 Facade
• 每个 Facade 负责一个特定的子系统

3. 接口隔离

// 分离接口
interface OrderFacade {
    void processOrder();
}

interface PaymentFacade {
    void processPayment();
}

4. 限制知识范围

• Facade 不需要知道所有细节
• 只暴露必要的功能

好的实践示例

// 分离关注点的 Facade 实现
class OrderProcessingFacade {
    private OrderValidator validator;
    private OrderProcessor processor;
    private NotificationService notifier;

    public OrderResult processOrder(Order order) {
        // 只协调核心流程，不包含具体实现
        if (validator.validate(order)) {
            OrderResult result = processor.process(order);
            notifier.notify(result);
            return result;
        }
        return OrderResult.failed();
    }
}

总结

• Facade 模式本身是好的，问题在于实现方式
• 避免让 Facade 承担过多责任
• 保持 Facade 的简单性和专注性
• 如果发现 Facade 变得过于复杂，考虑拆分成多个专门的 Facade

记住：好的 Facade 应该像一个优秀的管理者，知道如何委派工作，而不是事事亲力亲为