设计模式——外观模式(Facade)

外观模式(Facade Pattern) 是一种结构型设计模式,它为一个子系统中的一组接口提供一个统一的高层接口,使得子系统更加容易使用。这种类型的设计模式属于结构型模式,它向客户端提供了一个接口,隐藏了子系统的复杂性。

1. 定义与特点

  • 定义:外观模式为多个复杂的子系统提供一个对外的接口,使这些子系统更加容易的被访问。该模式对外有一个统一的接口,外部应用不用关心子系统内部的细节,大大降低了应用程序的复杂度,提高了可维护性。
  • 特点
    • 简化了调用过程,应用无需深入了解子系统。
    • 减少系统依赖,松散耦合。
    • 更好的划分访问层次。
    • 符合迪米特法则(最少知道原则)。

然而,外观模式也有一些缺点,比如增加子系统或扩展子系统行为容易引入风险,以及不符合开闭原则(即对扩展开放,对修改关闭)。

2. 角色

  • 外观(Facade)角色:这是模式的核心,客户端可以调用这个角色的方法。外观类知晓相关的(一个或者多个)子系统的功能和责任。在正常情况下,本角色会将所有从客户端发来的请求委派到相应的子系统去。
  • 子系统(Subsystem)角色:可以同时有一个或者多个子系统。每一个子系统都不是一个单独的类,而是一个类的集合。每一个子系统都可以被客户端直接调用,或者被外观角色调用。子系统并不知道外观的存在,对于子系统而言,外观仅仅是另外一个客户端而已。
  • 用户(Client)角色:用户通过外观类调用子系统的功能。

3. 适用场景

  • 子系统复杂:当子系统越来越复杂,增加外观模式可以提供简单调用接口。
  • 构建多层系统结构:利用外观对象作为每层的入口,简化层级调用。

4. 优缺点

  • 优点
    • 降低了子系统与客户端之间的耦合度,使得子系统内部的变化不会影响客户端。
    • 隐藏了子系统的复杂性,客户端只需要与外观类进行交互,无需了解子系统内部的实现细节。
    • 提高了系统的灵活性和可扩展性,通过修改外观类,可以很容易地改变子系统的行为。
  • 缺点
    • 在不恰当的情况下使用外观模式,可能会增加系统的复杂性,因为需要创建额外的外观类来管理子系统的接口。
    • 如果外观类过度使用,可能会导致它成为一个"上帝类",该类知道太多的子系统细节,并承担过多的责任。这可能会使得系统的维护和扩展变得困难。

5. 示例

以下是一个简单的Java代码示例,演示了外观模式(Facade Pattern)的应用:

java 复制代码
// 子系统A
class SubSystemA {
    public void operationA() {
        System.out.println("Subsystem A operationA() called.");
    }
}

// 子系统B
class SubSystemB {
    public void operationB() {
        System.out.println("Subsystem B operationB() called.");
    }
}

// 子系统C
class SubSystemC {
    public void operationC() {
        System.out.println("Subsystem C operationC() called.");
    }
}

// 外观类
class Facade {
    private SubSystemA subSystemA;
    private SubSystemB subSystemB;
    private SubSystemC subSystemC;

    public Facade() {
        subSystemA = new SubSystemA();
        subSystemB = new SubSystemB();
        subSystemC = new SubSystemC();
    }

    // 提供给客户端调用的简单接口
    public void operation() {
        subSystemA.operationA();
        subSystemB.operationB();
        subSystemC.operationC();
    }
}

// 客户端代码
public class Client {
    public static void main(String[] args) {
        // 使用外观类
        Facade facade = new Facade();
        facade.operation(); // 客户端只需要调用外观类的方法
    }
}

在这个示例中,我们有三个子系统类:SubSystemASubSystemBSubSystemC。每个子系统类都有一个操作方法(operationA()operationB()operationC())。然后,我们创建了一个外观类 Facade,该类聚合了这些子系统对象,并提供了一个 operation() 方法供客户端调用。在这个 operation() 方法中,我们按顺序调用了子系统的各个方法。

在客户端代码中,我们只需要创建一个 Facade 对象,并调用其 operation() 方法,而无需关心子系统内部的实现细节。这样,客户端与子系统之间的耦合度就降低了,同时提高了系统的灵活性和可扩展性。

相关推荐
博风27 分钟前
设计模式:6、装饰模式(包装器)
设计模式
A_cot28 分钟前
理解设计模式与 UML 类图:构建稳健软件架构的基石
microsoft·设计模式·简单工厂模式·工厂方法模式·uml
君败红颜30 分钟前
设计模式之创建模式篇
设计模式
闲人一枚(学习中)4 小时前
设计模式-创建型-抽象工厂模式
设计模式·抽象工厂模式
小白不太白9506 小时前
设计模式之 观察者模式
观察者模式·设计模式
小白不太白9507 小时前
设计模式之 责任链模式
python·设计模式·责任链模式
吾与谁归in7 小时前
【C#设计模式(13)——代理模式(Proxy Pattern)】
设计模式·c#·代理模式
吾与谁归in7 小时前
【C#设计模式(14)——责任链模式( Chain-of-responsibility Pattern)】
设计模式·c#·责任链模式
闲人一枚(学习中)8 小时前
设计模式-创建型-原型模式
设计模式
Iced_Sheep8 小时前
干掉 if else 之策略模式
后端·设计模式