### 外观模式 为子系统中的一组接口提供一个一致的界面，此模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。（摘抄） 外观模式体现了依赖倒转原则和迪米特法则，抽出来一个外观类作为客户端调用接口，当客户端调用的时候只需要知道外观类的方法和实现的效果即可，而不需要去知道具体的功能类做了那些工作，其实仔细看外观模式也会有很多前面提到过的设计模式的影子，这些影子就是设计模式的原则和法则，所以把原则弄明白了一切的设计模式都不在话下，会被我们踩在脚下的 ~~~ class A { public void methodA() { //A的操作 } } class B { public void methodB() { //B的操作 } } class C { public void methodC() { //C的操作 } } class D { public void methodD() { //D的操作 } } class Facade { A a; B b; C c; D d; public Facede() { // TODO Auto-generated constructor stub a = new A(); b = new B(); c = new C(); d = new D(); } public void method1() { a.methodA(); b.methodB(); } public void method2() { c.methodC(); d.methodD(); } } class Client { public static void main() { Facede facade = new Facade(); facade.method1(); facade.method2(); } } ~~~ 简单的代码实现就在上面了，首先要弄清楚这个外观模式在什么时候调用，外观模式是一个提供给客户调用功能类的接口，他自己本身是和功能类没有任何关系的。 在平时给软件设计系统时也应该做到把层与层之间的划分做得很清晰，同时随着功能类的越来越多，提供一个简单的调用接口，可以有效的减少层与层之间的耦合。 他的好处还有当你要给客户端修改调用的功能类时直接更改外观类中的代码就行了。 同时当你需要给一个别人写的软件拓展功能的时候，例如一个小插件，但是如果这个软件很庞大，代码调用很繁杂，这时你开发一个Facade类，把需要调用的类和一些代码处理的工作交给Facade，那你开发小插件调用的时候就会很方便而且很清晰，因为Facade都已经整理好了，而且你要是要写多个小插件，但是功能又有重叠的地方，那么这个Facade的作用就更大了