『设计模式』外观模式--这篇博客也太明了吧
外部与一个子系统的通信必须通过一个统一的外观（Facade）对象进行，这就是外观模式。
- 外观模式要求一个子系统的外部与其内部的通信必须通过一个统一的外观（Facade）对象进行。外观模式提供一个高层次的接口，是的子系统更易于使用。
- 外观模式的外观类将客户端与子系统的内部复杂性分隔开，使得客户端只需要与外观对象打交道，而不需要与子系统内部的很多对象打交道。
外观模式的结构
- 外观（Facade）角色
客户端可以调用这个角色的方法。此角色知晓相关的（一个或者多个）子系统的功能和责任。在正常情况下，本角色会将所有从客户端发来的请求委派到相应的子系统去。 - 子系统（subsystem）角色
可以同时有一个或者多个子系统。每一个子系统都不是一个单独的类，而是一个类的集合。每一个子系统都可以被客户端直接调用，或者被门面角色调用。子系统并不知道门面的存在，对于子系统而言，门面仅仅是另外一个客户端而已。
【GOF】的书中指出
在外观模式中，通常只需要一个外观类，并且此外观类只有一个实例，换言之它是一个单例类。当然这并不意味着在整个系统里只能有一个外观类，而仅仅是说对每一个子系统只有一个外观类。或者说，如果有一个系统有好几个子系统的话，每一个子系统有一个外观类，整个系统可以有数个外观类。
当客户程序与抽象类的实现部分之间存下着很大的依赖性，引入Facade将这个子系统与客户一集其他的子系统分离，为一个复杂子系统提供一个简单接口，Facade可以提供一个简单地缺省视图，这一视图对大多数用户来说已经足够，而那些需要更多的可定制性的用户可以越过Facade层。可以提高子系统的独立性和可移植性。
- 在层次化结构中，可以使用Facade模式定义系统中每一层的入口点，如果子系统之间是相互依赖的，则可以让他们仅通过Facade进行通信，从而简化他们之间的依赖关系。
- 希望包装或隐藏原有系统：Facade可以把原有系统作为自己的私有成员。原有系统与Facade类联系在一起，但使用Facade类的客户无法看到原有的系统。
维护一个一流的大型系统。
跟踪对系统的使用——强迫所有客户通过Facade使用原有系统。
优点
- 屏蔽了外部客户端和系统每部模块的交互
- Facade的功能可以被多个客户端调用，可以实现复用（功能的共享）
- 对使用Facade的人员来说，Facade大大的节省了他们的学习成本。
缺点
不符合开闭原则。
本质
封装交互、简化调用
就是将各种方法封装到门面类中，用户只能看到门面类，也不需要知道真实的方法类，做到了隔离。
实现：
public class ModuleA {
//示意方法
public void MethodA(){
System.out.println("调用ModuleA中的MethodA方法");
}
}
public class ModuleB {
//示意方法
public void MethodB(){
System.out.println("调用ModuleB中的MethodB方法");
}
}
public class ModuleC {
//示意方法
public void MethodC(){
System.out.println("调用ModuleC中的MethodC方法");
}
}
门面角色类：
public class Facade {
//示意方法，满足客户端需要的功能
ModuleA a；
ModuleA b;
ModuleA c;
Facade(){
a = new ModuleA();
b = new ModuleB();
c = new ModuleC();
}
public void MethodA(){
a.MethodA();
b.MethodB();
}
public void MethodB(){
b.MethodB();
c.MethodC();
}
}
客户端角色类：
public class Client {
public static void main(String[] args) {
Facade facade = new Facade();
facade.MethodA();
facade.MethodB();
}
}
