外观模式

一，模式简介

​1.外观模式要求一个子系统的外部与其内部的通信必须通过一个统一的外观（Facade）对象进行。外观模式提供一个高层次的接口，使得子系统更易于使用

2.就例如医院的接待员一样，外观模式的外观类将客户端与子系统的内部复杂性分隔开，使得客户端只需要与外观对象打交道，而不需要与子系统内部的很多对象打交道

3.外观模式没有具体的UML图

有一个概括的图

二，模式解析

1.（1）外观（Facade）角色：客户端可以调用这个角色的方法。此角色知晓相关的（一个或者多个）子系统的功能和责任。在正常情况下，本角色会将所有的从客户端发来的请求委派到相应的子系统中去

（2）子系统角色（subsystem）角色：可以同时有一个或者多个子系统。每一个子系统都不是一个单独的类，而是一个类的集合。每一个子系统都可以被客户端直接调用，或者被门面角色调用。子系统并不知道门面的存在，对于子系统而言，门面仅仅是另外一个客户端而已

2.一个系统可以有几个外观类

如果一个系统有好几个子系统的话，每一个子系统有一个外观类，整个系统可以有数个外观类

3.应用场景

• 为一个复杂的子系统提供一个简单接口的时候

• 当客户端程序与抽象类的实现部分之间存在着很大的依赖性的时候，可以引入Facade将这个子系统与客户以及其他的子系统分离，可以提高子系统的独立性和可移植性

• 在层次化的结构中，可以使用Facade模式定义系统中每一层的入口点，如果子系统之间是相互依赖的，则可以让他们仅仅通过Facade进行通信，从而简化他们之间的依赖关系

• 希望包装或隐藏原有的系统：Facade可以把原来的系统作为自己的私有成员。原有系统与Facade类联系起来，但使用Facade类的客户无法看到原有的系统

• 可以用在：维护一个遗留的大型系统，跟踪对系统的使用--强迫所有客户通过Facade使用原有系统

4.模式优点：

• 屏蔽了外部客户端和系统内部模块的交互

• Facade的功能可以被多个客户端调用，可以实现被多个客户端调用，可以实现复用（功能的共享）

• 对使用Facade的人员来说，Facade大大的节省了他们的学习成本

5.模式缺点

不符合开闭原则

6.模式本质

封装交互，简化调用