设计模式之外观模式

“外观模式”名词解释：

　　为复杂的系统提供简单的访问接口来供外部调用，避免直接与系统内部交涉而产生的问题
　

“外观模式”示意图：

未使用外观模式的系统示意图：

使用外观模式的系统示意图：

其实很容易比较两种方式的优缺点：
1）未使用外观模式：系统调用关系繁杂，还很难保证调用关系不会出错；对子系统的侵入性太强；后期维护麻烦。
2）使用外观模式：外部系统统一使用模板接口进行调用，开发者主要关注模板接口的开发即可；减少对子系统侵入性；减轻后期维护难度。

“外观模式”使用场景：

根据《大话设计模式》一书的整理：在一个完整项目开发周期中，可能会在三个阶段使用到外观模式，具体如下：

1. 在项目设计初期，有意识将不同的两个层进行分离。比如经典的三层模型中，层与层之间通过接口进行调用，降低各层之间的耦合度。
2. 在项目开发阶段，子系统会随着项目的不断重构演化而变得越来越复杂，这对项目本身来说是一件好事，但是对外部系统调用程序来说，并不是一件好事，所以增添外观模式，提供一个简单的系统调用接口显得尤为重要。
3. 在项目维护阶段，当项目开发至一定程度时，可能系统已经很难维护和扩展，直接在原有代码的基础上进行项目重构显然是不成熟的做法，我们可以对原有系统进行整理和归纳，使用外观模式开发一个新的Facade类，来调用原有系统底层，实现项目重构包装。说个开发的题外话，一个系统的功能可以很多，但千万不能乱，系统功能乱了，就全毁了。这有个标准，自己负责的模块可以很轻松地画出执行流程图。