设计模式之外观模式

外观模式是一种使用频率非常高的结构型设计模式，它通过引入一个外观角色来简化客户端与子系统之间的交互，为复杂的子系统调用提供一个统一的入口，降低子系统与客户端的耦合程度，且客户端调用非常方便。

不知道大家有没有比较过自己做饭和去参观吃饭的去边，如果自己做饭需要自行准备做饭的材料，锅、油盐酱醋等，但是如果去饭店吃饭的话那就不一样了，服务员会给你一个菜单，你告诉服务员要吃什么菜，然后服务员去下单。也就是因为饭店有服务员的存在，我们不需要直接和这些材料直接的接触，整个做饭的过程由饭店厨师来完成，我们只需要与服务员进行简单的沟通就好了，整个过程非常的省事。

什么是外观模式

外观模式：亦称“过程模式”。学校课程评价模式之一。美国教育学者斯泰克1967年在所著《教育评价的外观》中提出。主张按照描述和判断资料来评价课程，关键的活动是在课程实施的全过程中进行观察和搜集意见，以了解人们对课程的不同看法。这种模式不限于检查教学的成果，重视描述和判断教学过程中各种复杂、动态的现象和事物。 —— 节选自百度百科

外观类为包含许多活动部件的复杂子系统提供一个简单的接口。与直接调用子系统相比，外观提供的功能可能比较有限， 但它却包含了客户端真正关心的功能。如果你的程序需要与包含几十种功能的复杂库整合， 但只需使用其中非常少的功能， 那么使用外观模式会非常方便。

外观模式中一个子系统的外部与其内部的通信通过一个统一的外观类进行，外观类将客户类与子系统的内部复杂性分隔开，是的客户类只需要与外观角色打交道，而不需要与子系统内部的很多对象打交道。

外观模式优缺点

在团队协作时，我们每个人都会负责不同的模块，有些模块可能会被拆解成更多的子模块。不是模块负责人，可能很难搞清楚这些细碎的小模块要如何做合起来完成工作。这个时候，我们也可以提供外观模式的总接口，这样，负责其它模块的同事不需要搞清楚我的模块的内在逻辑，他只需要引用我的外观模式类，然后调用那个类里的方法，就能完成工作。

优点

1. 降低了子系统与客户端之间的耦合度，使得子系统的变化不会影响调用它的客户类
2. 对客户屏蔽了子系统组件，减少了客户处理的对象数目，并使得子系统使用起来更加容易
3. 降低了大型软件系统中的编译依赖性，简化了系统在不同平台之间的移植过程，因为编译一个子系统不会影响其他的子系统，也不会影响外观对象

缺点

1. 不能很好地限制客户使用子系统类，很容易带来未知风险
2. 增加新的子系统可能需要修改外观类或客户端的源代码，违背了开闭原则

示例

外观模式的主要角色如下：

1. 外观：提供了一种访问特定子类系统功能的便捷方法，其了解如何重定向客户端请求，知晓如何操作一切活动部件
2. 创建附加外观：类可以避免多种不相关的功能，污染单一外观，使其变成有一个复杂结构，客户端和其他外观都可以使用附加外观
3. 复杂子系统：由数十个不同的对象构造。如果要用这些对象完成有意义的工作，你必须深入了解子系统的实现细节，比如按照正确顺序初始化对象和为其提供正确的格式数据
4. 客户端：使用外观代替对子系统的直接调用

类图如下所示：

代码示例：

class SubSystemA {

  public MethodA():void{
    console.log("SubSystemA:业务实现代码")
  }

}

class SubSystemB {

  public MethodB():void{
    console.log("SubSystemB:业务实现代码")
  }

}

class Facade {
  private obj1:SubSystemA = new SubSystemA();
  private obj2:SubSystemB = new SubSystemB();

  public Method():void  {
    this.obj1.MethodA();
    this.obj2.MethodB();
  }
}

class Program {

  private facade:Facade = new Facade();

  public start():void {
    this.facade.Method();
  }

}

const program = new Program();
program.start();

总结

外观模式从整体来说还是相对比较好理解，这种思想再日常开发中应用场景有很多，从使用体验来说，外观模式和语法糖很像。使用外观模式，可以大大减少我们纠缠在语法实现的时间消耗，更容易专注于业务逻辑。

同样的，对于一些我们并不清楚内在逻辑的功能，外观模式还能赋予我们更强的实现能力，让我们更专注在自己负责的模块，提高团队协作的效率。