一.外观模式简介
外观模式属于结构型模式。
外观模式为子系统中的一组接口提供了一个一致的界面，外观模式定义了一个高层接口，这个接口使得子系统更加容易使用。
当你要为一个复杂的系统提供一个简单的接口时，子系统往往因为不断演化而变的越来越复杂。大多数模式使用时都会产生更多更小的类。这使得子系统更具有可重用性，更容易对子系统进行定制，但这也会给那些不需要定制子系统的用户带来一些使用上的困难。
外观模式为了解决3的痛点，提供了一个简单的缺省视图，这一视图对大多数用户来说已经足够，而那些需要更多的可定制性的用户可以越过外观层。
客户程序与抽象类的实现部分存在着很大的依赖性，引入外观模式可以将这个子系统与客户以及其他子系统分离，可以提高子系统的独立性和可移植性。
优点：
引入外观模式，客户对子系统的使用变得简单了。减少了与子系统的关联对象，实现了子系统与客户之间的松耦合。
只是提供了一个访问子系统的统一入口，并不影响用户直接使用子系统类
降低了大型软件系统中的编译依赖性，并简化了系统在不同平台之间的移植过程。
缺点：
不能很好的限制客户使用子系统类，如果堆客户访问子系统做太多的限制则减少了灵活性和可变性。
在不引入抽象外观类的情况下，增加新的子系统可能需要修改外观类或客户端的源码，违背了开闭原则。
个人感觉，外观类只不过把具体的业务逻辑模块化了，这样的聚合在层次鲜明，耦合本身比较低或者逻辑流程比较统一的业务中值得考虑，但但业务流转的太复杂有可能导致父系统上面又聚合父系统，这样层次关系会很乱。所以这种模式不值得在复杂多变的逻辑处理中推荐。
二.测试代码
public class WaiguanMoshiTest { public static void main(String[] args) { Facade facade=new Facade(); facade.methodA(); facade.methodB(); }}interface ServiceA{ void methodA();}interface ServiceB{ void methodB();}interface ServiceC{ void methodC();}class ServiceAimpl implements ServiceA{ @Override public void methodA() { System.out.println("服務a"); } }class ServiceBimpl implements ServiceB{ @Override public void methodB() { System.out.println("服務b"); } }class ServiceCimpl implements ServiceC{ @Override public void methodC() { System.out.println("服務c"); } }class Facade{ ServiceA serviceA; ServiceB serviceB; ServiceC serviceC; public Facade(){ serviceA=new ServiceAimpl(); serviceB=new ServiceBimpl(); serviceC=new ServiceCimpl(); } public void methodA(){ serviceA.methodA(); serviceB.methodB(); } public void methodB(){ serviceB.methodB(); serviceC.methodC(); } public void methodC(){ serviceC.methodC(); serviceA.methodA(); }}