Java设计模式-外观模式

一、外观模式的定义

外观模式（Facade Pattern）是一种结构型设计模式，它为子系统中的一组接口提供一个一致的高层接口，使得子系统更容易使用2。通过引入一个外观类，将复杂的子系统接口进行封装，充当客户端与子系统之间的中间人，处理客户端的请求并将其转发给适当的子系统，客户端无需了解底层子系统的复杂性。

二、外观模式角色构成

• 外观（Facade）角色：为多个子系统对外提供一个统一、简化的接口，内部依赖并调用多个子系统模块，将客户端的请求代理给适当的子系统对象1。
• 子系统（Subsystem）角色：包含实际的业务逻辑和复杂的功能实现，由多个模块或类组成，负责完成具体的任务，通过外观类与客户端交互1。

三、外观模式适用场景

• 复杂系统简化访问：当系统由多个复杂的子系统组成时，如大型企业级应用包含订单系统、库存系统、支付系统等，使用外观模式可以为这些子系统提供一个统一的接口，让开发人员无需了解每个子系统的详细接口和交互细节，降低开发难度12。
• 分层架构通信：在分层架构中，如 MVC 架构，外观模式通常用于在控制器层统一调用服务层的多个模块，使得各层之间的接口更加清晰，降低层与层之间的耦合度。
• 第三方库集成：使用第三方库时，其接口可能与自身系统的设计风格和接口要求不一致，通过外观模式可以将第三方库的接口封装成符合自身系统要求的接口，便于集成和使用。

四、外观模式优缺点

• 优点简化操作：客户端只需要与外观类交互，无需了解和调用多个子系统的复杂接口，大大简化了客户端的操作12。降低耦合：将客户端与子系统解耦，子系统的内部变化不会直接影响到客户端，提高了系统的可维护性和可扩展性12。提高可读性：外观类提供了一个清晰的高层接口，使得代码结构更加清晰，易于理解和维护。
• 缺点限制灵活性：不能很好地控制客户端直接使用子系统类，如果对客户端访问子系统类做过多限制，会减少系统的可变性和灵活性。可能违反开闭原则：如果子系统发生较大变化，或者需要添加新的子系统，可能需要修改外观类的源代码，违背了开闭原则。

五、外观模式Java代码样例

// 子系统1
class Subsystem1 {
    public void method1() {
        System.out.println("Subsystem1 method1");
    }
}

// 子系统2
class Subsystem2 {
    public void method2() {
        System.out.println("Subsystem2 method2");
    }
}

// 外观类
class Facade {
    private Subsystem1 subsystem1;
    private Subsystem2 subsystem2;

    public Facade() {
        subsystem1 = new Subsystem1();
        subsystem2 = new Subsystem2();
    }

    public void methodA() {
        subsystem1.method1();
        subsystem2.method2();
    }

    public void methodB() {
        subsystem2.method2();
        subsystem1.method1();
    }
}

// 客户端
public class Client {
    public static void main(String[] args) {
        Facade facade = new Facade();
        facade.methodA();
        facade.methodB();
    }
}

在上述代码中，Subsystem1和Subsystem2是具体的子系统，实现了各自的功能。Facade是外观类，它封装了对子系统的调用，为客户端提供了methodA和methodB两个简单的接口。客户端只需要与Facade类交互，而不需要直接操作子系统，从而简化了客户端的代码，降低了耦合度。