設計模式總結篇系列:外觀模式(Facade)
阿新 • • 發佈:2019-02-01
張三自從畢業後開始做軟體開發,做著做著發現不爽了,錢賺不了太多,頭髮也白了。於是拿著一點小資本,想著做點小生意。瞅著眼前的餐飲行業還不錯,於是打算開一家餐館。開參觀可不是一件容易的事,僅僅行政類的審批流程就不少。至少包括辦理衛生許可證,辦理稅務登記,辦理工商登記等。
我們先來看一下行政審批介面:
1 interface Executive{
2
3 public void approve();
4
5 }
衛生局類的定義:
1 class HealthOffice implements Executive{
2
3 @Override
4 public void approve() {
5 System.out.println("衛生局通過審批");
6 }
7
8 }
稅務局類的定義:
1 class RevenueOffice implements Executive{
2
3 @Override
4 public void approve() {
5 System.out.println("稅務局完成登記,定時回去收稅");
6 }
7
8 }
工商局類的定義:
1 class SaicOffice implements Executive{
2
3 @Override
4 public void approve() {
5 System.out.println("工商局完成稽核,辦法營業執照");
6 }
7
8 }
好了,現在客戶端需要上場了:
1 public class FacadeTest {
2
3 public static void main(String[] args) {
4 System.out.println("開始辦理行政手續...");
5
6 HealthOffice ho = new HealthOffice();
7 RevenueOffice ro = new RevenueOffice();
8 SaicOffice so = new SaicOffice();
9
10 ho.approve();
11 ro.approve();
12 so.approve();
13
14 System.out.println("行政手續終於辦完了");
15 }
16
17 }
當然,上面的各個方法不一定都是實現同一個介面的,只是在這個例子中巧合了下。
我們發現,對客戶端而言,想要的最終目的和關心的是辦理完開飯店的行政審批手續,如果以辦理行政手續為一個子系統來看的話,我們發現,上面的設計中客戶端直接與子系統內的多個模組進行了互動,對客戶端而言,比較麻煩,使得客戶端不能簡單的使用系統功能,且隨著子系統模組的變換客戶端可能也需要隨著變化。
我們可以通過外觀模式來解決上述問題,外觀模式的一般描述是:外觀模式定義了一個高層的功能,為子系統中的多個模組協同的完成某種功能需求提供簡單的對外功能呼叫方式,使得這一子系統更加容易被外部使用。
利用外觀模式對上述類進行重定義。定義一個外觀類:
1 class ApproveFacade {
2
3 public ApproveFacade() {
4
5 }
6
7 public void wholeApprove() {
8 new HealthOffice().approve();
9 new RevenueOffice().approve();
10 new SaicOffice().approve();
11 }
12
13 }
客戶端呼叫:
1 public class FacadeTest {
2
3 public static void main(String[] args) {
4 System.out.println("開始辦理行政手續...");
5
6 ApproveFacade af = new ApproveFacade();
7 af.wholeApprove();
8
9 System.out.println("行政手續終於辦完了");
10 }
11
12 }
看,通過外觀模式後客戶端呼叫夠簡單了吧。
外觀模式的目的不是給予子系統新增新的功能介面,而是為了讓外部減少與子系統內多個模組的互動,鬆散耦合,從而讓外部能夠更簡單地使用子系統。
外觀模式的本質是:封裝互動,簡化呼叫。
---------------------------------------------------------------------------------