第23章 門面模式
23.1 我要投遞信件
我們都寫過紙質信件吧,比如給女朋友寫情書什么的。寫信的過程大家應該都還記得——先寫信的內容,然后寫信封,再把信放到信封中,封好,投遞到信箱中進行郵遞,這個過程還是比較簡單的,雖然簡單,但是這4個步驟都不可或缺!我們先把這個過程通過程序實現出來,如圖23-1所示。

圖23-1 寫信過程類圖
這一個過程還是比較簡單的,我們看程序的實現,先看接口,如代碼清單23-1所示。
代碼清單23-1 寫信過程接口
public?interface?ILetterProcess?{
?????//首先要寫信的內容
?????public?void?writeContext(String?context);
?????//其次寫信封
?????public?void?fillEnvelope(String?address);
?????//把信放到信封里
?????public?void?letterInotoEnvelope();
?????//然后郵遞
?????public?void?sendLetter();
}
在接口中定義了完成的一個寫信過程,這個過程需要實現,其實現類如代碼清單23-2所示。
代碼清單23-2 寫信過程的實現
public?class?LetterProcessImpl?implements?ILetterProcess?{
?????//寫信
?????public?void?writeContext(String?context)?{
?????????????System.out.println("填寫信的內容..."?+?context);
?????}
?????//在信封上填寫必要的信息
?????public?void?fillEnvelope(String?address)?{
?????????????System.out.println("填寫收件人地址及姓名..."?+?address);
?????}
?????//把信放到信封中,并封好
?????public?void?letterInotoEnvelope()?{
?????????????System.out.println("把信放到信封中...");
?????}
?????//塞到郵箱中,郵遞
?????public?void?sendLetter()?{
?????????????System.out.println("郵遞信件...");
?????}
}
在這種環境下,最累的是寫信人,為了發送一封信要有4個步驟,而且這4個步驟還不能顛倒,我們先看看這個過程如何通過程序表現出來,有人開始用這個過程寫信了,如代碼清單23-3所示。
代碼清單23-3 場景類
public?class?Client?{
?????public?static?void?main(String[]?args)?{
?????????????//創建一個處理信件的過程
?????????????ILetterProcess?letterProcess?=?new?LetterProcessImpl();
?????????????//開始寫信
?????????????letterProcess.writeContext("Hello,It's?me,do?you?know?who?I?am??I'm?your?old?lover.?I'd?like?to...");?????
?????????????//開始寫信封
?????????????letterProcess.fillEnvelope("Happy?Road?No.?666,God?Province,Heaven");
?????????????//把信放到信封里,并封裝好
?????????????letterProcess.letterInotoEnvelope();
?????????????//跑到郵局把信塞到郵箱,投遞
?????????????letterProcess.sendLetter();
?????}
}
運行結果如下所示:
填寫信的內容...Hello,It's me,do you know who I am? I'm your old lover. I'd like to...
填寫收件人地址及姓名...Happy Road No. 666,God Province,Heaven
把信放到信封中...
郵遞信件...
我們回過頭來看看這個過程,它與高內聚的要求相差甚遠,更不要說迪米特法則、接口隔離原則了。你想想,你要知道這4個步驟,而且還要知道它們的順序,一旦出錯,信就不可能郵寄出去,這在面向對象的編程中是極度地不適合,它根本就沒有完成一個類所具有的單一職責。
還有,如果信件多了就非常麻煩,每封信都要這樣運轉一遍,非得累死,更別說要發個廣告信了,那怎么辦呢?還好,現在郵局開發了一個新業務,你只要把信件的必要信息告訴我,我給你發,我來完成這4個過程,只要把信件交給我就成了,其他就不要管了。非常好的方案!我們來看類圖,如圖23-2所示。

圖23-2 增加現代化郵局的類圖
這還是比較簡單的類圖,增加了一個ModenPostOffice類,負責對一個比較復雜的信件處理過程的封裝,然后高層模塊只要和它有交互就成了,如代碼清單23-4所示。
代碼清單23-4 現代化郵局
public?class?ModenPostOffice?{
?????private?ILetterProcess?letterProcess?=?new?LetterProcessImpl();
?????//寫信,封裝,投遞,一體化
?????public?void?sendLetter(String?context,String?address){
?????????????//幫你寫信
?????????????letterProcess.writeContext(context);
?????????????//寫好信封
?????????????letterProcess.fillEnvelope(address);
?????????????//把信放到信封中
?????????????letterProcess.letterInotoEnvelope();
?????????????//郵遞信件
?????????????letterProcess.sendLetter();
?????}
}
這個類是什么意思呢,就是說現在有一個Hell Road PostOffice(地獄路郵局)提供了一種新型服務,客戶只要把信的內容以及收信地址給他們,他們就會把信寫好,封好,并發送出去。這種服務推出后大受歡迎,這多簡單,客戶減少了很多工作,誰不樂意呀。那我們看看客戶是怎么調用的,如代碼清單23-5所示。
代碼清單23-5 場景類
public?class?Client?{
?????public?static?void?main(String[]?args)?{
?????????????//現代化的郵局,有這項服務,郵局名稱叫Hell?Road
?????????????ModenPostOffice?hellRoadPostOffice?=?new?ModenPostOffice();
?????????????//你只要把信的內容和收信人地址給他,他會幫你完成一系列的工作
?????????????//定義一個地址
?????????????String?address?=?"Happy?Road?No.?666,God?Province,Heaven";
?????????????//信的內容
?????????????String?context?=?"Hello,It's?me,do?you?know?who?I?am??I'm?your?old?lover.?I'd?like?to....";
?????????????//你給我發送吧
?????????????hellRoadPostOffice.sendLetter(context,?address);
?????}
}
運行結果是相同的。我們看看場景類是不是簡化了很多,只要與ModenPostOffice交互就成了,其他的什么都不用管,寫信封啦、寫地址啦……都不用關心,只要把需要的信息提交過去就成了,郵局保證會按照我們指定的地址把指定的內容發送出去,這種方式不僅簡單,而且擴展性還非常好,比如一個非常時期,寄往God Province(上帝省)的郵件都必須進行安全檢查,那我們就很好處理了,如圖23-3所示。

圖23-3 擴展后的系統類圖
增加了一個Police類,負責對信件進行檢查,如代碼清單23-6所示。
代碼清單23-6 信件檢查類
public?class?Police?{
?????//檢查信件,檢查完畢后警察在信封上蓋個戳:此信無病毒
?????public?void?checkLetter(ILetterProcess?letterProcess){
?????????????System.out.println(letterProcess+"?信件已經檢查過了...");
?????}
}
我們再來看一下封裝類ModenPostOffice的變更,它封裝了這部分的變化,如代碼清單23-7所示。
代碼清單23-7 擴展后的現代化郵局
public?class?ModenPostOffice?{
?????private?ILetterProcess?letterProcess?=?new?LetterProcessImpl();
?????private?Police?letterPolice?=?new?Police();
?????//寫信,封裝,投遞,一體化了
?????public?void?sendLetter(String?context,String?address){
?????????????//幫你寫信
?????????????letterProcess.writeContext(context);
?????????????//寫好信封
?????????????letterProcess.fillEnvelope(address);
?????????????//警察要檢查信件了
?????????????letterPolice.checkLetter(letterProcess);
?????????????//把信放到信封中
?????????????letterProcess.letterInotoEnvelope();
?????????????//郵遞信件
?????????????letterProcess.sendLetter();
?????}
}
只是增加了一個letterPolice變量的聲明以及一個方法的調用,那這個寫信的過程就變成這樣:先寫信、寫信封,然后警察開始檢查,之后才把信放到信封,最后發送出去,那這個變更對客戶來說是透明的,他根本就看不到有人在檢查他的郵件,他也不用了解,反正現代化的郵件系統都幫他做了,這也是他樂意的地方。
場景類還是完全相同,但是運行結果稍有不同,如下所示:
填寫信的內容...Hello,It's me,do you know who I am?I'm your old lover.I'd like to...
填寫收件人地址及姓名...Happy Road No.666,God Province,Heaven
com.cbf4life.common3.LetterProcessImpl@15ff48b 信件已經檢查過了...
把信放到信封中...
郵遞信件...
高層模塊沒有任何改動,但是信件卻已經被檢查過了。這正是我們設計所需要的模式,不改變子系統對外暴露的接口、方法,只改變內部的處理邏輯,其他兄弟模塊的調用產生了不同的結果,確實是一個非常棒的設計。這就是門面模式。
- 前言
- 第一部分 大旗不揮,誰敢沖鋒——6大設計原則全新解讀
- 第1章 單一職責原則
- 1.2 絕殺技,打破你的傳統思維
- 1.3 我單純,所以我快樂
- 1.4 最佳實踐
- 第2章 里氏替換原則
- 2.2 糾紛不斷,規則壓制
- 2.3 最佳實踐
- 第3章 依賴倒置原則
- 3.2 言而無信,你太需要契約
- 3.3 依賴的三種寫法
- 3.4 最佳實踐
- 第4章 接口隔離原則
- 4.2 美女何其多,觀點各不同
- 4.3 保證接口的純潔性
- 4.4 最佳實踐
- 第5章 迪米特法則
- 5.2 我的知識你知道得越少越好
- 5.3 最佳實踐
- 第6章 開閉原則
- 6.2 開閉原則的廬山真面目
- 6.3 為什么要采用開閉原則
- 6.4 如何使用開閉原則
- 6.5 最佳實踐
- 第二部分 真刀實槍 ——23種設計模式完美演繹
- 第7章 單例模式
- 7.2 單例模式的定義
- 7.3 單例模式的應用
- 7.4 單例模式的擴展
- 7.5 最佳實踐
- 第8章 工廠方法模式
- 8.2 工廠方法模式的定義
- 8.3 工廠方法模式的應用
- 8.4 工廠方法模式的擴展
- 8.5 最佳實踐
- 第9章 抽象工廠模式
- 9.2 抽象工廠模式的定義
- 9.3 抽象工廠模式的應用
- 9.4 最佳實踐
- 第10章 模板方法模式
- 10.2 模板方法模式的定義
- 10.3 模板方法模式的應用
- 10.4 模板方法模式的擴展
- 10.5 最佳實踐
- 第11章 建造者模式
- 11.2 建造者模式的定義
- 11.3 建造者模式的應用
- 11.4 建造者模式的擴展
- 11.5 最佳實踐
- 第12章 代理模式
- 12.2 代理模式的定義
- 12.3 代理模式的應用
- 12.4 代理模式的擴展
- 12.5 最佳實踐
- 第13章 原型模式
- 13.2 原型模式的定義
- 13.3 原型模式的應用
- 13.4 原型模式的注意事項
- 13.5 最佳實踐
- 第14章 中介者模式
- 14.2 中介者模式的定義
- 14.3 中介者模式的應用
- 14.4 中介者模式的實際應用
- 14.5 最佳實踐
- 第15章 命令模式
- 15.2 命令模式的定義
- 15.3 命令模式的應用
- 15.4 命令模式的擴展
- 15.5 最佳實踐
- 第16章 責任鏈模式
- 16.2 責任鏈模式的定義
- 16.3 責任鏈模式的應用
- 16.4 最佳實踐
- 第17章 裝飾模式
- 17.2 裝飾模式的定義
- 17.3 裝飾模式應用
- 17.4 最佳實踐
- 第18章 策略模式
- 18.2 策略模式的定義
- 18.3 策略模式的應用
- 18.4 策略模式的擴展
- 18.5 最佳實踐
- 第19章 適配器模式
- 19.2 適配器模式的定義
- 19.3 適配器模式的應用
- 19.4 適配器模式的擴展
- 19.5 最佳實踐
- 第20章 迭代器模式
- 20.2 迭代器模式的定義
- 20.3 迭代器模式的應用
- 20.4 最佳實踐
- 第21章 組合模式
- 21.2 組合模式的定義
- 21.3 組合模式的應用
- 21.4 組合模式的擴展
- 21.5 最佳實踐
- 第22章 觀察者模式
- 22.2 觀察者模式的定義
- 22.3 觀察者模式的應用
- 22.4 觀察者模式的擴展
- 22.5 最佳實踐
- 第23章 門面模式
- 23.2 門面模式的定義
- 23.3 門面模式的應用
- 23.4 門面模式的注意事項
- 23.5 最佳實踐
- 第24章 備忘錄模式
- 24.2 備忘錄模式的定義
- 24.3 備忘錄模式的應用
- 24.4 備忘錄模式的擴展
- 24.5 最佳實踐
- 第25章 訪問者模式
- 25.2 訪問者模式的定義
- 25.3 訪問者模式的應用
- 25.4 訪問者模式的擴展
- 25.5 最佳實踐
- 第26章 狀態模式
- 26.2 狀態模式的定義
- 26.3 狀態模式的應用
- 第27章 解釋器模式
- 27.2 解釋器模式的定義
- 27.3 解釋器模式的應用
- 27.4 最佳實踐
- 第28章 享元模式
- 28.2 享元模式的定義
- 28.3 享元模式的應用
- 28.4 享元模式的擴展
- 28.5 最佳實踐
- 第29章 橋梁模式
- 29.2 橋梁模式的定義
- 29.3 橋梁模式的應用
- 29.4 最佳實踐
- 第三部分 誰的地盤誰做主 ——設計模式PK
- 第30章 創建類模式大PK
- 30.1 工廠方法模式VS建造者模式
- 30.2 抽象工廠模式VS建造者模式
- 第31章 結構類模式大PK
- 31.1 代理模式VS裝飾模式
- 31.2 裝飾模式VS適配器模式
- 第32章 行為類模式大PK
- 32.1 命令模式VS策略模式
- 32.2 策略模式VS狀態模式
- 32.3 觀察者模式VS責任鏈模式
- 第33章 跨戰區PK
- 33.1 策略模式VS橋梁模式
- 33.2 門面模式VS中介者模式
- 33.3 包裝模式群PK
- 第四部分 完美世界 ——設計模式混編
- 第34章 命令模式+責任鏈模式
- 34.2 混編小結
- 第35章 工廠方法模式+策略模式
- 35.2 混編小結
- 第36章 觀察者模式+中介者模式
- 36.2 混編小結
- 第五部分 擴展篇
- 第37章 MVC框架
- 37.2 最佳實踐
- 第38章 新模式
- 38.1 規格模式
- 38.2 對象池模式
- 38.3 雇工模式
- 38.4 黑板模式
- 38.5 空對象模式
- 附錄 23種設計模式彩圖