Java设计模式-外观模式（Facade Pattern）

实现对象的复用–外观模式

定义：为子系统中的一组接口提供一个统一的入口。外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。

外观模式又称为门面模式，它是一种对象结构型模式。外观模式是迪米特法则的一种具体实现，通过引入一个新的外观角色可以降低原有系统的复杂度，同时降低客户类与子系统的耦合度。

举例：

一般情况下，要学习某个知识，每个人都得去找资料，每个人都要去学习，这个过程就比较麻烦，如果这个时候找个中间人，由中间人去找资料，然后分享给大家，这样就方便多了。如图：

外观UML类图如下：

• 客户端：调用方
• 外观角色（Facade）：在客户端可以调用它的方法，在外观角色中可以知道相关的（一个或者多个）子系统的功能和责任；在正常情况下，它将所有从客户端发来的请求委派到相应的子系统去，传递给相应的子系统对象处理。
• 子系统：每一个子系统可以不是一个单独的类，而是一个类的集合，它实现子系统的功能；每一个子系统都可以被客户端直接调用，或者被外观角色调用，它处理由外观类传过来的请求；子系统并不知道外观的存在，对于子系统而言，外观角色仅仅是另外一个客户端而已。

因为外观模式非常简单，省略举例。

外观模式总结

外观模式和工厂模式有点相似的地方，工厂模式中，客户端只用调用工厂，而不用管工厂内部实现，外观模式也是客户端只用调用外观角色，而不用管具体细节。

外观模式在一定程度上降低了类与类之间的耦合，引入外观模式后，新增和修改子系统都非常方便，在实现开发过程中，外观模式使用非常频繁。

在使用标准外观模式时，如果需要增加、删除或者更换与外观类交互的子系统，必须修改外观类或者客户端的源码，这违背了开闭原则。所以在使用外观模式时，可以引入抽象外观类，如图：

使用场景：

• 当涉及到与多个复杂系统频繁交互时，为了降低系统复杂程度，可以采用外观模式。
• 当需要构件一个层次结构的子系统时，使用外观模式定义系统中每层的入口点。

优点：

• 对客户端屏蔽了系统组件，减少了客户端的对象数目并使子系统使用起来更加容易，对象关联少了。
• 子系统和客户端松耦合，使得子系统变化后，客户端不需要变动。

缺点：

• 不能很好限制客户端使用子系统
• 新增子系统，可能需要修改外观类源码