如何让孩子爱上设计模式 ——11.外观模式(Facade Pattern)

标签： 设计模式初涉

---

场景引入

相信各位玩过LOL英雄联盟游戏的童鞋，对下面两个英雄都不会陌生吧：

     

分别是瑞雯和盲僧，这两个英雄都可以通过组合键的方式打出爆炸性伤害，
打出这套组合键除了需要较快的手速外，还需要记住键位顺序，对应技能：
瑞雯的光速QA：Q + 空格 + A + 鼠标左键 + Q + 空格 + A + 鼠标左键 + Q + 空格 + A + 鼠标左键
瞎子一秒七脚：Q + A + E + 九头蛇 + R + A + 闪现 + Q
注：光速QA的空格键是设置了大笑动作用来。

我们通过来演示下如何手把手打出这一波操作。

---

单身20年拼手速

先把各种需要用到的键位都列出来：A，E，Q，R，空格，闪现，九头蛇，鼠标左键

 

 

 

 

接着顺序我们依次按下对应按钮来打出连招

输出结果

尽管打出了连招，但是，每次按连招都需要把对应的每个键都操作一遍，
非常麻烦，而且对于我这种手残玩家，基本是按不出来的，有没有办法，
把每个按键的调用集成到一个键上，不用关心具体调用顺序与内容，只要
通过这个键就可以一键完成连招呢？当然是有的，通过外观模式可以
帮我们解决这个需求，我们将按键顺序(交互)封装到外挂(外观类)中。

---

手残党用脚本

非常简单，就是把调用逻辑抽取到外挂类中，暴露两个方法供玩家调用：

手残党玩家只需直接调用这个脚本即可完成一键光速QA和一秒7脚：

输出结果

用法非常简单，例子也很好理解，接下来直接上定义吧。

---

外观模式概念相关

定义

要求一个子系统的外部与内部的通信必须通过一个统一的对象进行，
外观模式提供一个高层次的接口，使得子系统更易于使用。
(其实就是封装，用于解决类与类间的依赖关系，比如本来是：
玩家依赖于：Q，A，E，R等键位对象，现在变成只依赖与脚本对象
从而降低了类间的耦合度。)

两个角色

• Facade：外观角色，客户端可以调用他的方法，在外观角色
  中可以知道相关子系统的功能和责任；在正常情况下，它将所有从客户
  端发来的请求委派到相应的子系统去，传递给相应的子系统对象处理。
• Subsystem：子系统角色，实现子系统的功能，处理外观类
  指派的任务，注意子系统类不含有外观类的引用

UML类图

使用场景

• 为访问一系列复杂的子系统提供一个简单的入口
• 客户端程序与多个子系统间存在很大的依赖性，可以引入外观模式帮助解耦
• 在层次化结构中，可以使用外观模式定义系统中每一层的入口，层与层间不
  直接产生联系，而通过外观类进行关联，降低层间的耦合度。

优缺点

优点：

• 降低客户端与子系统间的耦合度；
• 对客户屏蔽子系统组件，从而能简化接口，减少客户端处理的对象数目；
• 一个子系统的修改对其他子系统没有任何影响，而且子系统内部变化也不会影响到外观对象

缺点：

• 在不引入抽象外观类的情况下，增加新的子系统可能需要修改
  外观类或客户端的源代码，违背了"开闭原则"。
• 不能很好地限制客户使用子系统类，如果对客户访问子系统类
  做太多的限制则减少了可变性和灵活性。

---

本节代码：

https://github.com/coder-pig/DesignPatternsExample/tree/master/10.Facade%20Pattern

---