结构型模式：外观模式

简介

外观模式：是一种通过为多个复杂的子系统提供一个一致的接口，而使这些子系统更加容易被访问的模式。该模式对外有一个统一接口，外部应用程序不用关心内部子系统的具体细节，这样会大大降低应用程序的复杂度，提高了程序的可维护性。

其实就是一种封装，把一系列的操作封装成简单的接口供客户端去调用。但是不能滥用，因为本身就是为了减少客户端与各个依赖的耦合性，将一堆依赖改为依赖一个外观类。

外观模式遵循的是迪米特法则，也就是最少知道原则，但是如果新增新的功能，可能会改动到外观类，所以它违背了开闭原则。

它常常应用于SKD，开源类库这些，用于给外部提供精简的接口。

而我们js，可能并不需要去创建一个类，直接整个函数包一下就完事了。把一系列的操作封装到一个或者多个函数，然后export导出供外部使用。

代码实现

//功能1
class A {
  show() {
    console.log("触发了功能A");
  }
}

//功能B
class B {
  open() {
    console.log("触发了功能B");
  }
}

class C {
  hindele() {
    console.log("触发了功能C");
  }
}

//外观类
class Facade {
  a: A;
  b: B;
  c: C;

  constructor() {
    this.a = new A();
    this.b = new B();
    this.c = new C();
  }

  start() {
    this.a.show();
    this.c.hindele();
    this.b.open();
  }
}

//客户端
class Client {
  constructor() {
    const facade = new Facade();

    facade.start();
  }
}

外观模式的应用场景

通常在以下情况下可以考虑使用外观模式。

1. 对分层结构系统构建时，使用外观模式定义子系统中每层的入口点可以简化子系统之间的依赖关系。
2. 当一个复杂系统的子系统很多时，外观模式可以为系统设计一个简单的接口供外界访问。
3. 当客户端与多个子系统之间存在很大的联系时，引入外观模式可将它们分离，从而提高子系统的独立性和可移植性。

外观模式的扩展

在外观模式中，当增加或移除子系统时需要修改外观类，这违背了“开闭原则”。如果引入抽象外观类，则在一定程度上解决了该问题。

类图：

原来客户端依赖的是具体的外观类，现在改为依赖外观的抽象，当子系统发生改变时，我们可以新增一个新的外观类来替换旧的，这一定程度上满足了开闭原则。