設計模式總結篇系列：外觀模式（Facade）

張三自從畢業后開始做軟件開發，做着做着發現不爽了，錢賺不了太多，頭發也白了。於是拿着一點小資本，想着做點小生意。瞅着眼前的餐飲行業還不錯，於是打算開一家餐館。開參觀可不是一件容易的事，僅僅行政類的審批流程就不少。至少包括辦理衛生許可證，辦理稅務登記，辦理工商登記等。

我們先來看一下行政審批接口：

interface Executive{ 2     
    public void approve(); 4     
}

衛生局類的定義：

class HealthOffice implements Executive{ 2 
 @Override 4     public void approve() { 5         System.out.println("衛生局通過審批"); 6  } 7     
}

稅務局類的定義：

class RevenueOffice implements Executive{ 2 
 @Override 4     public void approve() { 5         System.out.println("稅務局完成登記，定時回去收稅"); 6  } 7     
}

工商局類的定義：

class SaicOffice implements Executive{ 2 
 @Override 4     public void approve() { 5         System.out.println("工商局完成審核，辦法營業執照"); 6  } 7     
}

好了，現在客戶端需要上場了：

public class FacadeTest {  2 
    public static void main(String[] args) {  4         System.out.println("開始辦理行政手續...");  5 
        HealthOffice ho = new HealthOffice();  7         RevenueOffice ro = new RevenueOffice();  8         SaicOffice so = new SaicOffice();  9 
 ho.approve(); 11  ro.approve(); 12  so.approve(); 13 
        System.out.println("行政手續終於辦完了"); 15  } 16 
}

當然，上面的各個方法不一定都是實現同一個接口的，只是在這個例子中巧合了下。

我們發現，對客戶端而言，想要的最終目的和關心的是辦理完開飯店的行政審批手續，如果以辦理行政手續為一個子系統來看的話，我們發現，上面的設計中客戶端直接與子系統內的多個模塊進行了交互，對客戶端而言，比較麻煩，使得客戶端不能簡單的使用系統功能，且隨着子系統模塊的變換客戶端可能也需要隨着變化。

我們可以通過外觀模式來解決上述問題，外觀模式的一般描述是：外觀模式定義了一個高層的功能，為子系統中的多個模塊協同的完成某種功能需求提供簡單的對外功能調用方式，使得這一子系統更加容易被外部使用。

利用外觀模式對上述類進行重定義。定義一個外觀類：

class ApproveFacade {  2 
    public ApproveFacade() {  4 
 }  6 
    public void wholeApprove() {  8         new HealthOffice().approve();  9         new RevenueOffice().approve(); 10         new SaicOffice().approve(); 11  } 12 
}

客戶端調用：

public class FacadeTest {  2 
    public static void main(String[] args) {  4         System.out.println("開始辦理行政手續...");  5 
        ApproveFacade af = new ApproveFacade();  7  af.wholeApprove();  8         
        System.out.println("行政手續終於辦完了"); 10  } 11 
}

看，通過外觀模式后客戶端調用夠簡單了吧。

外觀模式的目的不是給予子系統添加新的功能接口，而是為了讓外部減少與子系統內多個模塊的交互，松散耦合，從而讓外部能夠更簡單地使用子系統。

外觀模式的本質是：封裝交互，簡化調用。