外观模式

能为程序库、 框架或其他复杂类提供一个简单的接口

适用场景

• 需要一个指向复杂子系统的直接接口时，且该接口的功能有限，则可以使用外观模式

• 需要将子系统组织为多层结构，可以使用外观（Spring MVC 中的 Controller 就是典型的外观模式设计）

优/缺点

优点：

• 可以让自己的代码独立于复杂子系统

缺点：

• 外观可能成为与程序中所有类都耦合的上帝对象

对比其他模式

• 外观模式为现有对象定义了一个新接口，适配器模式则会试图运用已有的接口。 适配器通常只封装一个对象，外观通常会作用于整个对象子系统上。

• 只需对客户端代码隐藏子系统创建对象的方式时，你可以使用抽象工厂模式来代替外观

• 享元模式展示了如何生成大量的小型对象，外观则展示了如何用一个对象来代表整个子系统

• 外观和中介者模式的职责类似：它们都尝试在大量紧密耦合的类中组织起合作

  • 外观为子系统中的所有对象定义了一个简单接口，但是它不提供任何新功能。 子系统本身不会意识到外观的存在。子系统中的对象可以直接进行交流。

  • 中介者将系统中组件的沟通行为中心化。 各组件只知道中介者对象，无法直接相互交流。

• 外观类通常可以转换为单例模式类，因为在大部分情况下一个外观对象就足够了。

• 外观与代理模式的相似之处在于它们都缓存了一个复杂实体并自行对其进行初始化。 代理与其服务对象遵循同一接口，使得自己和服务对象可以互换，在这一点上它与外观不同。

实现示例

class VideoConverter {
  convert(file: File, format: string): File {}
}

function main() {
  const videoConverter = new VideoConverter();
  const mp4 = videoConverter.convert(new File('./video.ogg'), 'mp4');
}