设计模式以外观模式

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

不知道你们有没有比较过本身作饭和去参观吃饭的去边，若是本身作饭须要自行准备作饭的材料，锅、油盐酱醋等，可是若是去饭店吃饭的话那就不同了，服务员会给你一个菜单，你告诉服务员要吃什么菜，而后服务员去下单。也就是由于饭店有服务员的存在，咱们不须要直接和这些材料直接的接触，整个作饭的过程由饭店厨师来完成，咱们只须要与服务员进行简单的沟通就行了，整个过程很是的省事。

什么是外观模式

外观模式：亦称“过程模式”。学校课程评价模式之一。美国教育学者斯泰克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();

总结

外观模式从总体来讲仍是相对比较好理解，这种思想再平常开发中应用场景有不少，从使用体验来讲，外观模式和语法糖很像。使用外观模式，能够大大减小咱们纠缠在语法实现的时间消耗，更容易专一于业务逻辑。

一样的，对于一些咱们并不清楚内在逻辑的功能，外观模式还能赋予咱们更强的实现能力，让咱们更专一在本身负责的模块，提升团队协做的效率。