### 外觀模式 為子系統中的一組接口提供一個一致的界面，此模式定義了一個高層接口，這個接口使得這一子系統更加容易使用。（摘抄） 外觀模式體現了依賴倒轉原則和迪米特法則，抽出來一個外觀類作為客戶端調用接口，當客戶端調用的時候只需要知道外觀類的方法和實現的效果即可，而不需要去知道具體的功能類做了那些工作，其實仔細看外觀模式也會有很多前面提到過的設計模式的影子，這些影子就是設計模式的原則和法則，所以把原則弄明白了一切的設計模式都不在話下，會被我們踩在腳下的 ~~~ 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的作用就更大了