设计模式之门面模式Facade

门面模式也叫外观模式，是一种比较常用的封装模式。其定义为，要求一个子系统的外部与其内部的通信必须通过一个统一的对象进行。门面模式提供一个高层次的接口，使得子系统更易于使用。

优点：

- 减少系统的相互依赖。如果不适用门面模式，外界访问直接深入到子系统内部，相互之间就形成了一种强耦合关系，这样的强依赖是系统设计所不能接受的，门面模式就很好地解决了这个问题；

- 提高了灵活性。子系统内部可以随意改动，都不会影响到高层模块对子系统的调用；

- 提高安全性。想让你访问子系统的那些业务就开通哪些，不在门面上开通的方法，就不能访问；

缺点：不符合开闭原则。

注意事项：

1、一般情况下，一个子系统只要有一个门面就够了，但在以下几种情况中，可以有多个门面：

- 门面已经达到不能容忍的程度。比如一个纯洁的门面对象已经超过了200行代码，虽然都是简单的委托操作，也建议拆分成多个门面，否则会给以后的维护和扩展带来麻烦。对此，按照功能拆分是一个非常好的原则，比如一个数据库操作的门面可以拆分为查询门面、删除门面、更新门面等；

- 子系统可以提供不同的访问路径。

2、门面不参与子系统内的业务逻辑

比如门面有个methodA，methodB，和methodC三个方法，后面methodC的逻辑修改修改一下，必须先调用A，再调用C，程序如下图：

一开始大部分人都会这么直接在门面上改成这样子，但这样的设计师非常不靠谱的，因为门面对象参与了业务逻辑，门面对象只是提供一个访问子系统的一个路径而已，它不应该也不能参与具体的业务逻辑，否则就会产生一个倒依赖的问题：子系统必须依赖门面才能被访问，这是设计上一个严重错误，不仅违反了单一职责原则，同时也破坏了系统的封装性。

对此，重构后，新建立了一个封装类，封装完毕后提供给门面对象，代码如下：

该封装类的作用就是产生一个业务规则complexMethod，并且它的生存环境在子系统内，门面对象通过对它的访问完成了一个复杂的业务逻辑，代码如下：

通过这样一次封装后，门面对象又不参与业务逻辑了，在门面模式中，门面对象应该是稳定的，它不应该经常变化，一个系统一旦投入运行它就不应该被改变。