外观模式

外观模式的目的不是给子系统添加新的功能接口，而是为了让外部减少与子系统多个模块之间的交互，松散耦合，从而让外部能够更简单的使用子系统。

Facade模式方便了客户端的调用、封装了系统内部的细节功能、实现功能的共享和复用。
但是需要注意的是过多的或者不太合理的Facade也容易让人迷惑。

外观模式的本质是：封装交互，简化应用。
外观模式的设计原则是“最少知识原则”。

何时选用外观模式？
如果你希望为一个复杂的子系统提供一个简单接口的时候，可以考虑使用外观模式，使用外观模式来实现大部分的客户的需要的功能，从而简化客户的使用。
吐过想要让客户程序和抽象类的实现部分松散耦合，可以考虑使用外观模式，使用外观对象来将这个子系统与它的客户分离开来，从而提高子系统的独立性和可移植性。
如果构建多层结构的系统，可以考虑使用外观模式，使用外观对象作为每层的入口，这样就可以简化层之间的调用，也可以松散层次之间的耦合。典型使用就是MVC模式开发的service层。

下面是一个小例子：
说现在有一个可以“组装电脑”的子系统，细分为主机模块和显示屏模块。代码如下：

1. public interface AModule {
2.     void facadeA();
3. }
4.  
5. public class AModuleImpl implements AModule {
6.  
7.   @Override
8.  public void facadeA() {
9.       System.out.println("我是这台电脑的主机，负责运算");
10.   }
11.  
12. }
13.  
14. public interface BModule {
15.   void facadeB();
16. }
17.  
18. public class BModuleImpl implements BModule {
19.  
20.  @Override
21.     public void facadeB() {
22.      System.out.println("我是这台电脑的显示屏，负责视图");
23.  }
24.  
25. }

客户端的要求很简单，只需要服务端提供一台完整的电脑给我即可，客户端并不想知道这个电脑怎么组装。于是外观类出现了：

1. /**
2.  * 外观模式的facade，将模块目前已经存在的功能进行组装，
3.  * 并且暴露给Client，实现了客户端和业务模块之间的松耦合
4.  * (注意没有杜绝耦合，因为Client依然依赖Facade)
5.  * 
6.  * Facade的另外一个优势在于实现了代码的重用，大量的Client只需要使用Facade就可以了
7.  * 
8.  * 更好的方式是将facade作为借口暴露给客户端，这样的好处是可以设置"外观"的功能，这里为了简化演示就直接实现为普通java类
9.  * @author rao
10.  *
11.  */
12. public class Facade {
13.     public void createPC(){
14.      // 电脑主机
15.        AModule aModule = new AModuleImpl();
16.       aModule.facadeA();
17.       // 电脑显示屏
18.       BModule bModule = new BModuleImpl();
19.       bModule.facadeB();
20.   }
21. }

这样做客户端就可以轻而易举的拿到一台电脑了！

1. public class Client {
2.     public static void main(String[] args) {
3.        Facade facade = new Facade();
4.       facade.createPC();
5.    }
6. }