动机（Motivation）
如何简化外部客户程序和系统间的交互接口？如何
将外部客户程序的演化和内部子系统的变化之间的
依赖相互解耦？
意图（Intent）
为子系统中的一组接口提供一个一致的界面，
Fascade模式定义了一个高层接口，这个接口使得这
一子系统更加容易使用。
——《设计模式》GoF
Facade模式的几个要点
1.从客户程序的角度来看， Facade模式不仅简化了整个组
件系统的接口，同时对于组件内部与外部客户程序来说，
从某种程度上也达到了一种“解耦”的效果——内部子系统
的任何变化不会影响到Fa?ade接口的变化。
2。Fascade设计模式更注重从架构的层次去看整个系统，而
不是单个类的层次。Fa?ade很多时候更是一种架构设计
模式。
3 注意区分Fascade模式、Adapter模式、Bridge模式与
Decorator模式。Fascade模式注重简化接口，Adapter模式
注重转换接口，Bridge模式注重分离接口（抽象）与其实
现，Decorator模式注重稳定接口的前提下为对象扩展功
能。
Facade是内部各类的组合，如轮子，发动机等等组合成了车，这个车就是fascade。他屏蔽某一功能调用的复杂度，如开车，如果不使用fascade，我们就要分别去调用轮子类，发动机类等等，这样的调用是复杂，这种复杂对于调用者是困惑的，需要化很多时间去理解，这里要明白我们谈模式往往是要考虑项目的生命周期以及项目是由多个人合作完成的，fascade中就考虑了合作问题，他的合作是面向分层开发的合作，此合作模式下做界面的人去理解业务类的逻辑这是不合理的，要开车就直接调用开车函数这是最好的，所以就有了fascade，同时以后构成该功能的类发生了变化，比如，变飞车了，没有轮子了，但开车这一功能的参数和目标不变，在程序中就是说界面不变，有了fascade此时我们就可以仅仅修改业务逻辑。
internal 以前一直比较困惑，为什么要引入此修饰符，今天听了关于fascade的讲座，突然明白了，确实存在让其它程序集不能访问的情况，在fascade模式下，除了提供的facade其它的类就应该别认为是内部类，就不应该被访问，而使用internal就是为了达到这一目的，因为有时候有些人是很奇怪的，你定义了接口但他就是不用，你也毫无办法，那么我干脆就利用技术让你访问不了，一了百了。
