Facade（外观）--对象结构型模式

Facade（外观）–对象结构型模式

一、意图
为子系统中的一组接口提供一个一致的界面，Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。

二、动机

1.上述左边方案的问题在于组件的客户和组件中各种复杂的子系统有了过多的耦合，随着外部客户程序和各子系统的演化，这种过多的耦合面临很多变化的挑战。
2，如何简化外部客户程序和系统间的接口？如何将外部客户程序的演化和内部子系统的变化之间的依赖相互解耦？

三、适用性
1.当你要为一个复杂子系统提供一个简单的接口时。子系统往往因为不断演化而变得越来越复杂。大多数模式使用时都会产生更多更小的类。这使得子系统更具有可重用性，也更容易对子系统进行定制，但这也给那些不需要定制子系统的用户带来了一些使用上的困难。Facade可以提供一个简单的缺省视图，这一视图对大多数用户来说已经足够，而那些需要更多的可定制性的用户可以越过Facade层。
2.客户程序与抽象类的实现部分之间存在着很大的依赖性。引入facade将这个子系统与客户以及其他的子系统分离，可以提高子系统的独立性和可移植性。
3.当你需要构建一个层次结构的子系统时，使用facade模式定义子系统中每层的入口点。如果子系统之间是相互依赖的，你可以让它们仅通过facade进行通讯，从而简化了它们之间的依赖关系。

四、结构

五、效果
1.它对客户屏蔽子系统组件，因为减少了客户处理的对象的数目并使得子系统使用起来更加方便。
2.它实现了子系统与客户之间的耦合关系，而子系统内部的功能组件往往是紧耦合的。松耦合的关系是的子系统的组件变化不会影响到它的客户。Facade模式有助于建立层次结构系统，也有助于对对象之间的依赖关系分层。Facade模式可以消除复杂的循环依赖关系。这一点在客户程序与子系统时分别实现的时候尤为重要。
3.如果应用需要，它并不限制它们使用子类系统。因此你可以在系统易用性和通用型之间加以选择。

六、实现
1.降低客户-子系统之间的耦合度。
2.公共子系统与私有子系统类。

七、要点总结
1.从客户程序的角度来看，Facade模式简化了整个组件系统的接口，对于组件内部与外部客户程序来说，达到了一种“解耦”的效果——内部子系统的任何变化不会影响到Facade接口的变化。
2.Facade设计模式更注重从架构的层次看整个系统，而不是单个类的层次。Facade很多时候更是一种架构设计模式。
3.Facade设计模式并非一个集装箱，可以任意地放进任何多个对象。Facade模式中组件内部应该是“相互耦合关系比较大的一系统组件”，而不是一个简单的功能集合。

八、相关模式
Abstract Factory模式可以与Facade模式一起使用以提供一个接口，这一接口可用来以一种子系统独立的方式创建的子对象。Abstract Factroy也可以代替Facade模式隐藏那些与平台相关的类。
Mediator模式与Facade模式的相似之处是，它抽象了一些已有的类的功能。然而，Mediator的目的是对同事之间的任意通讯进行抽象，通常集中不属于任何单个对象的功能。Mediator的同事对象知道中介者并与它通信，而不是直接与其他对象通信。相对而言，Facade模式仅对于子系统对象的接口进行抽象，从而使它们更容易使用；它并不定义新功能。子系统也不知道facade的存在。
通常来讲，仅需要一个Facade对象，因此Facade对象通常属于Singleton模式。

九、举例说明
想了解一个村，简单的方式先问村长。

本文为李建忠设计模式视频的笔记以及《设计模式-可复用面向对象的软件的基础》和自己的部分见解