前言正式接觸使用設(shè)計(jì)模式近兩年了，一直想寫點(diǎn)東西來(lái)鞏固所學(xué)，但是遲遲沒有動(dòng)作，總想時(shí)間和見識(shí)再多一些的時(shí)候再動(dòng)筆，但是拖得越久越感覺合適的時(shí)機(jī)永遠(yuǎn)不會(huì)有，只有不斷實(shí)踐才能換來(lái)進(jìn)步，也許再不寫就永遠(yuǎn)也寫不出來(lái)了，于是我終于開始了。 談到設(shè)計(jì)模式，應(yīng)該還沒有人能超越GOF的開山之作，所以談不上什么創(chuàng)新，歸根結(jié)底還是重復(fù)前人的論述和思想，更多的只能是整理和個(gè)人的一些心得體會(huì)。因?yàn)閺脑O(shè)計(jì)模式誕生以來(lái)，業(yè)界還是發(fā)生了很大的變化的，開發(fā)工具和開發(fā)過(guò)程已經(jīng)更新?lián)Q代了很多次，所以很多模式在現(xiàn)在已經(jīng)不是很常用了，這次計(jì)劃只重點(diǎn)介紹最流行的模式，以后會(huì)逐漸補(bǔ)充其它的模式。(參看下面的提綱) 這個(gè)系列計(jì)劃以《Head First Design Patterns》的結(jié)構(gòu)為主線，也可以說(shuō)是這本書的學(xué)習(xí)筆記，但是更多的是學(xué)習(xí)原書循序漸進(jìn)的講解方式，再爭(zhēng)取加入更多個(gè)人的思想和見解，希望最后能引起大家的共鳴。 園子里已經(jīng)有好幾位大俠和前輩寫過(guò)設(shè)計(jì)模式系列的文章了，我從他們那曾經(jīng)吸收了太多的精華，大恩不言謝，我這里還是謝過(guò)了。 提綱下面是這個(gè)系列的提綱初稿，將來(lái)會(huì)根據(jù)實(shí)際情況做適當(dāng)?shù)脑鰟h。 開篇-模式和原則 1. 鴨子-策略模式 2. 氣象站的故事-觀察者模式 3. 來(lái)杯咖啡-裝飾者模式 4. 美味比薩-工廠模式 5. 巧克力-單件模式 6. 遙控器-命令模式 7. 家庭劇院-適配器和門面模式 8. 好萊塢原則-模板方法模式 9. 餐廳菜單-迭代器和合成模式 10. 糖果機(jī)-狀態(tài)模式 11. 首席代表-代理模式 12. 鴨子重出江湖-復(fù)合使用模式 13. 用模式思考-與模式相處 14. 剩下的模式 設(shè)計(jì)模式介紹模式：每一個(gè)模式描述了一個(gè)在我們周圍不斷重復(fù)發(fā)生的問(wèn)題，以及該問(wèn)題的解決方案的核心。 這是關(guān)于模式最經(jīng)典的定義，作者是建筑大師Christopher Alexander。如果是第一次看到這句話，多數(shù)人會(huì)覺得有些抽象難懂。其實(shí)“模式”兩個(gè)字只是一個(gè)代號(hào)，就像我叫Justin，如果我改叫Tom也沒什么問(wèn)題，只是我更喜歡Justin這個(gè)名字，所以從Christopher開始，有了“模式”這個(gè)詞，人們也都把關(guān)于“重復(fù)發(fā)生的問(wèn)題的描述和解決辦法”統(tǒng)稱為模式。 “模式”這個(gè)詞是不局限于軟件開發(fā)行業(yè)的，它幾乎無(wú)處不在，它其實(shí)就是一種經(jīng)驗(yàn)的積累，就象大多數(shù)人的教育經(jīng)歷都是從小學(xué)到初中再到高中再到大學(xué)，這也是一種模式，是中國(guó)的教育模式；現(xiàn)在越來(lái)越火的出國(guó)熱，也是另一種模式，海外留學(xué)模式。因?yàn)?/span>GOF的《設(shè)計(jì)模式：可復(fù)用面向?qū)ο筌浖幕A(chǔ)》一書描述的23種經(jīng)典設(shè)計(jì)模式，奠定了模式在軟件行業(yè)的地位，從此人們提到“設(shè)計(jì)模式”就是默指“面向?qū)ο笤O(shè)計(jì)模式”，但是如前文所述，模式絕對(duì)不局限于軟件行業(yè)，即使在軟件行業(yè)，也不局限于GOF描述的23種設(shè)計(jì)模式，例如最著名的Martin Flower的《企業(yè)架構(gòu)模式》，還有我們常用的MVC、IOC等。 [說(shuō)到這里，有必要聲明一下的是，在該系列文章中，凡提到模式，都是指軟件行業(yè)的基于GOF的《設(shè)計(jì)模式：可復(fù)用面向?qū)ο筌浖幕A(chǔ)》一書的面向?qū)ο笤O(shè)計(jì)模式，GRASP模式除外。] 因?yàn)槟Ｊ绞且环N經(jīng)驗(yàn)的積累和總結(jié)，所以通過(guò)模式，我們可以站在巨人的肩膀上去思考問(wèn)題、解決問(wèn)題，熟練使用設(shè)計(jì)模式可以提高我們的工作效率，改善產(chǎn)品質(zhì)量，最終帶來(lái)經(jīng)濟(jì)效益。因此對(duì)于任何想開發(fā)出靈活高效、健壯的軟件產(chǎn)品的個(gè)人或團(tuán)體，熟練掌握并正確使用設(shè)計(jì)模式都是必須掌握的基本技能。 所以，讓我們開始吧…… 比設(shè)計(jì)模式更重要：GRASP (職責(zé)分配原則)要學(xué)習(xí)設(shè)計(jì)模式，有些基礎(chǔ)知識(shí)是我們必須要先知道的，設(shè)計(jì)模式是關(guān)于類和對(duì)象的一種高效、靈活的使用方式，也就是說(shuō)，必須先有類和對(duì)象，才能有設(shè)計(jì)模式的用武之地，否則一切都是空談，那么類和對(duì)象是從那冒出來(lái)的呢？這時(shí)就需要比23種設(shè)計(jì)模式更重要更經(jīng)典的GRASP模式登場(chǎng)了，嘿嘿，原來(lái)這才是老大！ GRASP(General Responsibility Assignment Software Patterns)，中文名稱為“通用職責(zé)分配軟件模式”，GRASP一共包括9種模式，它們描述了對(duì)象設(shè)計(jì)和職責(zé)分配的基本原則。也就是說(shuō)，如何把現(xiàn)實(shí)世界的業(yè)務(wù)功能抽象成對(duì)象，如何決定一個(gè)系統(tǒng)有多少對(duì)象，每個(gè)對(duì)象都包括什么職責(zé)，GRASP模式給出了最基本的指導(dǎo)原則。初學(xué)者應(yīng)該盡快掌握、理解這些原則，因?yàn)檫@是如何設(shè)計(jì)一個(gè)面向?qū)ο笙到y(tǒng)的基礎(chǔ)。可以說(shuō)，GRASP是學(xué)習(xí)使用設(shè)計(jì)模式的基礎(chǔ)。
信息專家模式是面向?qū)ο笤O(shè)計(jì)的最基本原則，是我們平時(shí)使用最多，應(yīng)該跟我們的思想融為一體的原則。也就是說(shuō)，我們?cè)O(shè)計(jì)對(duì)象(類)的時(shí)候，如果某個(gè)類擁有完成某個(gè)職責(zé)所需要的所有信息，那么這個(gè)職責(zé)就應(yīng)該分配給這個(gè)類來(lái)實(shí)現(xiàn)。這時(shí)，這個(gè)類就是相對(duì)于這個(gè)職責(zé)的信息專家。 例如：常見的網(wǎng)上商店里的購(gòu)物車(ShopCar),需要讓每種商品(SKU)只在購(gòu)物車內(nèi)出現(xiàn)一次，購(gòu)買相同商品，只需要更新商品的數(shù)量即可。如下圖：
實(shí)際應(yīng)用中，符合下列任一條件的時(shí)候，都應(yīng)該由類Ａ來(lái)創(chuàng)建類Ｂ，這時(shí)Ａ是Ｂ的創(chuàng)建者： a. Ａ是Ｂ的聚合 b. Ａ是Ｂ的容器 c. Ａ持有初始化Ｂ的信息(數(shù)據(jù)) d. Ａ記錄Ｂ的實(shí)例 e. Ａ頻繁使用Ｂ 如果一個(gè)類創(chuàng)建了另一個(gè)類，那么這兩個(gè)類之間就有了耦合，也可以說(shuō)產(chǎn)生了依賴關(guān)系。依賴或耦合本身是沒有錯(cuò)誤的，但是它們帶來(lái)的問(wèn)題就是在以后的維護(hù)中會(huì)產(chǎn)生連鎖反應(yīng)，而必要的耦合是逃不掉的，我們能做的就是正確地創(chuàng)建耦合關(guān)系，不要隨便建立類之間的依賴關(guān)系，那么該如何去做呢？就是要遵守創(chuàng)建者模式規(guī)定的基本原則，凡是不符合以上條件的情況，都不能隨便用A創(chuàng)建B。 例如：因?yàn)橛唵?/span>(Order)是商品(SKU)的容器，所以應(yīng)該由訂單來(lái)創(chuàng)建商品。如下圖：
低耦合模式的意思就是要我們盡可能地減少類之間的連接。 其作用非常重要： a. 低耦合降低了因一個(gè)類的變化而影響其他類的范圍。 b. 低耦合使類更容易理解，因?yàn)轭悤?huì)變得簡(jiǎn)單，更內(nèi)聚。 下面這些情況會(huì)造成類A、B之間的耦合： a. A是B的屬性 b. A調(diào)用B的實(shí)例的方法 c. A的方法中引用了B，例如B是A方法的返回值或參數(shù)。 d. A是B的子類，或者A實(shí)現(xiàn)了B 關(guān)于低耦合，還有下面一些基本原則： a. Don’t Talk to Strangers原則： 意思就是說(shuō)，不需要通信的兩個(gè)對(duì)象之間，不要進(jìn)行無(wú)謂的連接，連接了就有可能產(chǎn)生問(wèn)題，不連接就一了百了啦！ b. 如果A已經(jīng)和B有連接，如果分配A的職責(zé)給B不合適的話(違反信息專家模式)，那么就把B的職責(zé)分配給A。 c. 兩個(gè)不同模塊的內(nèi)部類之間不能直接連接，否則必招報(bào)應(yīng)！嘿！ 例如：Creator模式的例子里，實(shí)際業(yè)務(wù)中需要另一個(gè)出貨人來(lái)清點(diǎn)訂單(Order)上的商品(SKU)，并計(jì)算出商品的總價(jià)，但是由于訂單和商品之間的耦合已經(jīng)存在了，那么把這個(gè)職責(zé)分配給訂單更合適，這樣可以降低耦合，以便降低系統(tǒng)的復(fù)雜性。如下圖：
 4. High cohesion (高內(nèi)聚) 高內(nèi)聚的意思是給類盡量分配內(nèi)聚的職責(zé)，也可以說(shuō)成是功能性內(nèi)聚的職責(zé)。即功能性緊密相關(guān)的職責(zé)應(yīng)該放在一個(gè)類里，并共同完成有限的功能，那么就是高內(nèi)聚合。這樣更有利于類的理解和重用，也便于類的維護(hù)。 高內(nèi)聚也可以說(shuō)是一種隔離，就想人體由很多獨(dú)立的細(xì)胞組成，大廈由很多磚頭、鋼筋、混凝土組成，每一個(gè)部分(類)都有自己獨(dú)立的職責(zé)和特性，每一個(gè)部分內(nèi)部發(fā)生了問(wèn)題，也不會(huì)影響其他部分，因?yàn)楦邇?nèi)聚的對(duì)象之間是隔離開的。 例如：一個(gè)訂單數(shù)據(jù)存取類(OrderDAO)，訂單即可以保存為Excel模式，也可以保存到數(shù)據(jù)庫(kù)中；那么，不同的職責(zé)最好由不同的類來(lái)實(shí)現(xiàn)，這樣才是高內(nèi)聚的設(shè)計(jì)，如下圖：
 5. Controller (控制器) 用來(lái)接收和處理系統(tǒng)事件的職責(zé)，一般應(yīng)該分配給一個(gè)能夠代表整個(gè)系統(tǒng)的類，這樣的類通常被命名為“XX處理器”、“XX協(xié)調(diào)器”或者“XX會(huì)話”。 關(guān)于控制器類，有如下原則： a. 系統(tǒng)事件的接收與處理通常由一個(gè)高級(jí)類來(lái)代替。 b. 一個(gè)子系統(tǒng)會(huì)有很多控制器類，分別處理不同的事務(wù)。 關(guān)于這個(gè)模式更詳細(xì)的論述，請(qǐng)參考《UML和模式應(yīng)用》第16章。 6. Polymorphism (多態(tài)) 這里的多態(tài)跟OO三大基本特征之一的“多態(tài)”是一個(gè)意思。 例如：我們想設(shè)計(jì)一個(gè)繪圖程序，要支持可以畫不同類型的圖形，我們定義一個(gè)抽象類Shape,矩形(Rectangle)、圓形(Round)分別繼承這個(gè)抽象類，并重寫(override)Shape類里的Draw()方法，這樣我們就可以使用同樣的接口(Shape抽象類)繪制出不同的圖形，如下圖：
 7. Pure Fabrication (純虛構(gòu)) 這里的純虛構(gòu)跟我們常說(shuō)的純虛構(gòu)函數(shù)意思相近。高內(nèi)聚低耦合，是系統(tǒng)設(shè)計(jì)的終極目標(biāo)，但是內(nèi)聚和耦合永遠(yuǎn)都是矛盾對(duì)立的。高內(nèi)聚以為這拆分出更多數(shù)量的類，但是對(duì)象之間需要協(xié)作來(lái)完成任務(wù)，這又造成了高耦合，反過(guò)來(lái)毅然。該如何解決這個(gè)矛盾呢，這個(gè)時(shí)候就需要純虛構(gòu)模式，由一個(gè)純虛構(gòu)的類來(lái)協(xié)調(diào)內(nèi)聚和耦合，可以在一定程度上解決上述問(wèn)題。 例如：上面多態(tài)模式的例子，如果我們的繪圖程序需要支持不同的系統(tǒng)，那么因?yàn)椴煌到y(tǒng)的API結(jié)構(gòu)不同，繪圖功能也需要不同的實(shí)現(xiàn)方式，那么該如何設(shè)計(jì)更合適呢？如下圖：
 8. Indirection (間接) “間接”顧名思義，就是這個(gè)事不能直接來(lái)辦，需要繞個(gè)彎才行。繞個(gè)彎的好處就是，本來(lái)直接會(huì)連接在一起的對(duì)象彼此隔離開了，一個(gè)的變動(dòng)不會(huì)影響另一個(gè)。就想我在前面的低耦合模式里說(shuō)的一樣，“兩個(gè)不同模塊的內(nèi)部類之間不能直接連接”，但是我們可以通過(guò)中間類來(lái)間接連接兩個(gè)不同的模塊，這樣對(duì)于這兩個(gè)模塊來(lái)說(shuō)，他們之間仍然是沒有耦合/依賴關(guān)系的。 9. Protected Variations (受保護(hù)變化) 預(yù)先找出不穩(wěn)定的變化點(diǎn)，使用統(tǒng)一的接口封裝起來(lái)，如果未來(lái)發(fā)生變化的時(shí)候，可以通過(guò)接口擴(kuò)展新的功能，而不需要去修改原來(lái)舊的實(shí)現(xiàn)。也可以把這個(gè)模式理解為OCP(開閉原則)原則，就是說(shuō)一個(gè)軟件實(shí)體應(yīng)當(dāng)對(duì)擴(kuò)展開發(fā)，對(duì)修改關(guān)閉。在設(shè)計(jì)一個(gè)模塊的時(shí)候，要保證這個(gè)模塊可以在不需要被修改的前提下可以得到擴(kuò)展。這樣做的好處就是通過(guò)擴(kuò)展給系統(tǒng)提供了新的職責(zé)，以滿足新的需求，同時(shí)又沒有改變系統(tǒng)原來(lái)的功能。關(guān)于OCP原則，后面還會(huì)有單獨(dú)的論述。 比設(shè)計(jì)模式更重要：設(shè)計(jì)原則我們生活在一個(gè)充滿規(guī)則的世界里，在復(fù)雜多變的外表下，萬(wàn)事萬(wàn)物都被永恒的真理支配并有規(guī)律的運(yùn)行著。模式也是一樣，不論那種模式，其背后都潛藏著一些“永恒的真理”，這個(gè)真理就是設(shè)計(jì)原則。記得一次參加微軟的架構(gòu)師培訓(xùn)，期間講到設(shè)計(jì)模式，有人問(wèn)了老師一個(gè)問(wèn)題：“什么東西比設(shè)計(jì)模式更重要？”，老師是一位有多年豐富實(shí)踐經(jīng)驗(yàn)的開發(fā)者，他毫不猶豫地回答到：“比模式更重要的是原則”。這句話我時(shí)常能夠想起，越來(lái)越覺得這是一個(gè)偉大的答案。的確，還有什么比原則更重要呢？就像人的世界觀和人生觀一樣，那才是支配你一切行為的根本，而對(duì)于設(shè)計(jì)模式來(lái)說(shuō)，為什么這個(gè)模式要這樣解決這個(gè)問(wèn)題，而另一個(gè)模式要那樣，它們背后都遵循的就是永恒的設(shè)計(jì)原則。可以說(shuō)，設(shè)計(jì)原則是設(shè)計(jì)模式的靈魂。 對(duì)于設(shè)計(jì)原則的深入探討我還沒有那個(gè)深度，推薦大家去看《敏捷軟件開發(fā)—原則、模式與實(shí)踐》，下面僅對(duì)部分常用的設(shè)計(jì)原則做些簡(jiǎn)單的講解： 1. 單一職責(zé)原則(SRP) “就一個(gè)類而言，應(yīng)該僅有一個(gè)引起它變化的原因?！币簿褪钦f(shuō)，不要把變化原因各不相同的職責(zé)放在一起，因?yàn)椴煌淖兓瘯?huì)影響到不相干的職責(zé)。再通俗一點(diǎn)地說(shuō)就是，不該你管的事情你不要管，管好自己的事情就可以了，多管閑事害了自己也害了別人。(當(dāng)然這里說(shuō)的多管閑事跟見義勇為是兩回事，我們提倡見義勇為！) 例如：參考下圖中的設(shè)計(jì)，圖形計(jì)算程序只使用了正方形的Area()方法，永遠(yuǎn)不會(huì)使用Draw()方法，而它卻跟Draw方法關(guān)聯(lián)了起來(lái)。這違反了單一原則，如果未來(lái)因?yàn)閳D形繪制程序?qū)е?/span>Draw()方法產(chǎn)生了變化，那么就會(huì)影響到本來(lái)毫不關(guān)系的圖形計(jì)算程序。
 “軟件實(shí)體(類、模塊、函數(shù)等)應(yīng)該是可以擴(kuò)展的，但是不可修改?！焙伲《嗝礃銓?shí)的話語(yǔ)，第一次看這個(gè)原則的時(shí)候我都看傻了，我當(dāng)時(shí)在想“這不是&#%做白日夢(mèng)嗎！不修改怎么擴(kuò)展??？”但是隨著學(xué)習(xí)的深入，理解了這個(gè)“不修改”是什么意思，意思是“你可以隨便增加新的類，但是不要修改原來(lái)的類”。從這個(gè)角度去理解就好多了，其實(shí)這里還是一個(gè)隔離變化的問(wèn)題。 例如：如下圖，有一個(gè)客戶端程序通過(guò)數(shù)據(jù)訪問(wèn)接口操作數(shù)據(jù)，對(duì)于這套系統(tǒng)來(lái)說(shuō)，一開始計(jì)劃使用的是SQL Server或Oracle數(shù)據(jù)庫(kù)，但是后來(lái)考慮到成本，改用免費(fèi)的MySQL；那么對(duì)于客戶端程序來(lái)說(shuō)，后來(lái)數(shù)據(jù)的擴(kuò)展對(duì)它沒有任何影響，它在不知不覺間就用上了免費(fèi)好用的MySQL數(shù)據(jù)庫(kù)，這全要感謝OCP原則。
 3. 依賴倒置原則(DIP) “抽象不應(yīng)該依賴于細(xì)節(jié)。細(xì)節(jié)應(yīng)該依賴于抽象。”關(guān)于這個(gè)原則，還有種說(shuō)法是.“高層不應(yīng)該依賴于底層，兩者都應(yīng)該依賴于抽象?！逼鋵?shí)怎么說(shuō)都是對(duì)的，關(guān)鍵就是要理解一點(diǎn)，只有抽象的東西才是最穩(wěn)定的，也就是說(shuō)，我們依賴的是它的穩(wěn)定。如果將來(lái)“抽象”也不穩(wěn)定了，那么誰(shuí)穩(wěn)定我跟誰(shuí)，其實(shí)說(shuō)白了不就是傍大款嗎！哈哈！ 例如：參考下圖的設(shè)計(jì)，一個(gè)開關(guān)跟燈直接連接在一起了，也就是說(shuō)開關(guān)依賴于燈的打開和關(guān)閉方法，那么如果我想用這個(gè)開關(guān)也可以打開其他東西呢，比如電視、音響。顯然這個(gè)設(shè)計(jì)是無(wú)法滿足這個(gè)要了，因?yàn)槲覀円蕾嚵思?xì)節(jié)而不是抽象，這個(gè)開關(guān)已經(jīng)等價(jià)于“燈的開關(guān)”。
 “不應(yīng)該強(qiáng)迫客戶依賴于它們不用的方法。接口屬于客戶，不屬于它所在的類層次結(jié)構(gòu)?！边@個(gè)說(shuō)得很明白了，再通俗點(diǎn)說(shuō)，不要強(qiáng)迫客戶使用它們不用的方法，如果強(qiáng)迫用戶使用它們不使用的方法，那么這些客戶就會(huì)面臨由于這些不使用的方法的改變所帶來(lái)的改變。 例如：參考下圖的設(shè)計(jì)，在這個(gè)設(shè)計(jì)里，取款、存款、轉(zhuǎn)帳都使用一個(gè)通用界面接口，也就是說(shuō)，每一個(gè)類都被強(qiáng)迫依賴了另兩個(gè)類的接口方法，那么每個(gè)類有可能因?yàn)榱硗鈨蓚€(gè)類的方法(跟自己無(wú)關(guān))而被影響。拿取款來(lái)說(shuō)，它根本不關(guān)心“存款操作”和“轉(zhuǎn)帳操作”，可是它卻要受到這兩個(gè)方法的變化的影響，真是土鱉?。?！
“子類型必須能夠替換掉它們的基類型?！币簿褪钦f(shuō)繼承中的“IS A”關(guān)系是必須保證的，否則還算什么繼承?。∪绻`反了LSP原則，常會(huì)導(dǎo)致在運(yùn)行時(shí)(RTTI)的類型判斷違反OCP原則。 例如：函數(shù)A的參數(shù)是基類型，調(diào)用時(shí)傳遞的對(duì)象是子類型，正常情況下，增加子類型都不會(huì)影響到函數(shù)A的，如果違反了LSP，則函數(shù)A必須小心的判斷傳進(jìn)來(lái)的具體類型，否則就會(huì)出錯(cuò)，這就已經(jīng)違反了OCP原則。
|
|
|
來(lái)自： Tom.Lin > 《設(shè)計(jì)模式》
