门面设计模式12
一、定义
门面模式又称为外观模式，该模式把一个模块中的多个类的公共接口封装到一个“统一接口”中，而门面类拥有一个或多个这样的“统一接口”。再简单一点理解就是封装“流程”，简化调用。
为多个复杂的子系统提供一个统一的访问入口
最简单的例子就是一个电脑，封装了CPU、内存、显卡等。电脑视为门面，我们与电脑打交道。
另外就是Activity工作流的很多Service，我们可以将其全部封装到一个类中，然后封装指定的流程，客户端只需要提供参数，例如任务的ID。
推荐我认为非常非常好的博客：
外观模式（Facade模式）详解 （核心）
设计模式（七）门面模式（Facade Pattern 外观模式）
二、外观设计模式的角色
-----> 表示是临时性的关联。在代码中，某个类的方法通过局部变量、方法的参数或者对静态方法的调用来访问另一个类
门面角色。门面类持有子系统角色的引用，因此熟悉子系统中的所有公共接口，并能够调用它们。
子系统角色：一个子系统类可以视为一个独立的模块，这个模块中实现了大量的业务逻辑功能。一个门面类中可以有多个子系统类。
客户端角色：什么是客户端，我的理解就是最上层调用环境。它专门调用门面角色。
三、优缺点
核心心法：门面设计模式是组合现有的功能
客户端不与各个子系统或者功能模块直接打交道，降低客户端复杂度。
缺点也很明显，当子系统功能修改的时候，门面里面也要修改相关的代码。（以前在调用环境要动的代码，现在挪到门面里面去动了）
优点：
1.降低调用环境与子系统之间的耦合，调用环境只与门面类耦合，而不与多个子系统类耦合。当需求发生变更的时候，编写新的门面类，替换掉原来的门面类。
2.简单好用。因为门面类中封装子系统类，可以将它们的业务逻辑流程封装到一个统一方法中，调用环境只需要直接调用门面类的那个统一方法，因此简单好用
3.在层次化结构中，可以使用外观模式定义系统中每一层的入口，层与层之间不直接产生联系，而通过外观类建立联系，降低层之间的耦合度。
缺点：
因为需求变更导致的逻辑代码变动，导致以前的门面类不能满足现在的需求，因此需要修改原来的代码，不符合开放闭合原则。解决方法是把门面类也抽象，编写新的门面类实现抽象门面类，使用修改配置文件的方法替换旧的门面类。但这样，无异于要编写读取配置文件的流操作代码，可以预见到，很可能有一个专门生成门面实现类的单例工厂，这样无异于增加了代码开发量。
四、心法
封装交互，简化调用，降低耦合。
层与层之间使用门面对接，封装了不同层次的交互。
不要试图去修改门面类的代码，更不要去继承或者代理门面类。
门面模式是负责“组合”子系统已有的功能，用于提供给现外部，满足需要，而不是添加新的实现。
我认为不需要创建过多的门面类，只让门面类去做封装那些较为复杂的流程操作。而子系统的一些简单的功能，调用环境仍然可以直接调用，而不是画蛇添足，为了设计模式而设计模式，没必要把一两步的操作也封装到门面类中。
五、实际使用
Shiro安全框架的Subject类就是一个非常典型门面类，组合了认证、授权、会话管理等多个复杂子系统。
经典的MVC模式就是经典的分层模式，Controller视为调用环境，不与DAO层直接交互。
分割线--------------------------------------------------------------------------------------------
下一篇：桥接设计模式13
刻意练习
（1）门面设计模式的定义
（2）门面设计模式核心心法
（3）优点、缺点
（4）实际用过的场景
