模式和原则 [原]
模式和原則
設計模式介紹
模式：每一個模式描述了一個在我們周圍不斷重復發(fā)生的問題，以及該問題的解決方案的核心。
這是關(guān)于模式最經(jīng)典的定義，作者是建筑大師Christopher Alexander。如果是第一次看到這句話，多數(shù)人會覺得有些抽象難懂。其實“模式”兩個字只是一個代號，就像我叫Justin，如果我改叫Tom也沒什么問題，只是我更喜歡Justin這個名字，所以從Christopher開始，有了“模式”這個詞，人們也都把關(guān)于“重復發(fā)生的問題的描述和解決辦法”統(tǒng)稱為模式。
“模式”這個詞是不局限于軟件開發(fā)行業(yè)的，它幾乎無處不在，它其實就是一種經(jīng)驗的積累，就象大多數(shù)人的教育經(jīng)歷都是從小學到初中再到高中再到大學，這也是一種模式，是中國的教育模式；現(xiàn)在越來越火的出國熱，也是另一種模式，海外留學模式。因為GOF的《設計模式：可復用面向?qū)ο筌浖幕A》一書描述的23種經(jīng)典設計模式，奠定了模式在軟件行業(yè)的地位，從此人們提到“設計模式”就是默指“面向?qū)ο笤O計模式”，但是如前文所述，模式絕對不局限于軟件行業(yè)，即使在軟件行業(yè)，也不局限于GOF描述的23種設計模式，例如最著名的Martin Flower的《企業(yè)架構(gòu)模式》，還有我們常用的MVC、IOC等。
[說到這里，有必要聲明一下的是，在該系列文章中，凡提到模式，都是指軟件行業(yè)的基于GOF的《設計模式：可復用面向?qū)ο筌浖幕A》一書的面向?qū)ο笤O計模式，GRASP模式除外。]
因為模式是一種經(jīng)驗的積累和總結(jié)，所以通過模式，我們可以站在巨人的肩膀上去思考問題、解決問題，熟練使用設計模式可以提高我們的工作效率，改善產(chǎn)品質(zhì)量，最終帶來經(jīng)濟效益。因此對于任何想開發(fā)出靈活高效、健壯的軟件產(chǎn)品的個人或團體，熟練掌握并正確使用設計模式都是必須掌握的基本技能。
所以，讓我們開始吧……
比設計模式更重要：GRASP (職責分配原則)
要學習設計模式，有些基礎知識是我們必須要先知道的，設計模式是關(guān)于類和對象的一種高效、靈活的使用方式，也就是說，必須先有類和對象，才能有設計模式的用武之地，否則一切都是空談，那么類和對象是從那冒出來的呢？這時就需要比23種設計模式更重要更經(jīng)典的GRASP模式登場了，嘿嘿，原來這才是老大！
GRASP(General Responsibility Assignment Software Patterns)，中文名稱為“通用職責分配軟件模式”，GRASP一共包括9種模式，它們描述了對象設計和職責分配的基本原則。也就是說，如何把現(xiàn)實世界的業(yè)務功能抽象成對象，如何決定一個系統(tǒng)有多少對象，每個對象都包括什么職責，GRASP模式給出了最基本的指導原則。初學者應該盡快掌握、理解這些原則，因為這是如何設計一個面向?qū)ο笙到y(tǒng)的基礎。可以說，GRASP是學習使用設計模式的基礎。
1.????? Information Expert (信息專家)
信息專家模式是面向?qū)ο笤O計的最基本原則，是我們平時使用最多，應該跟我們的思想融為一體的原則。也就是說，我們設計對象(類)的時候，如果某個類擁有完成某個職責所需要的所有信息，那么這個職責就應該分配給這個類來實現(xiàn)。這時，這個類就是相對于這個職責的信息專家。
例如：常見的網(wǎng)上商店里的購物車(ShopCar),需要讓每種商品(SKU)只在購物車內(nèi)出現(xiàn)一次，購買相同商品，只需要更新商品的數(shù)量即可。如下圖：
?
針對這個問題需要權(quán)衡的是，比較商品是否相同的方法需要放到那里類里來實現(xiàn)呢？分析業(yè)務得知需要根據(jù)商品的編號(SKUID)來唯一區(qū)分商品，而商品編號是唯一存在于商品類里的，所以根據(jù)信息專家模式，應該把比較商品是否相同的方法放在商品類里。??
2.????? Creator (創(chuàng)造者)
實際應用中，符合下列任一條件的時候，都應該由類Ａ來創(chuàng)建類Ｂ，這時Ａ是Ｂ的創(chuàng)建者：
a.?????? Ａ是Ｂ的聚合
b.?????? Ａ是Ｂ的容器
c.?????? Ａ持有初始化Ｂ的信息(數(shù)據(jù))
d.?????? Ａ記錄Ｂ的實例
e.?????? Ａ頻繁使用Ｂ
如果一個類創(chuàng)建了另一個類，那么這兩個類之間就有了耦合，也可以說產(chǎn)生了依賴關(guān)系。依賴或耦合本身是沒有錯誤的，但是它們帶來的問題就是在以后的維護中會產(chǎn)生連鎖反應，而必要的耦合是逃不掉的，我們能做的就是正確地創(chuàng)建耦合關(guān)系，不要隨便建立類之間的依賴關(guān)系，那么該如何去做呢？就是要遵守創(chuàng)建者模式規(guī)定的基本原則，凡是不符合以上條件的情況，都不能隨便用A創(chuàng)建B。
例如：因為訂單(Order)是商品(SKU)的容器，所以應該由訂單來創(chuàng)建商品。如下圖：
?
?????? 這里因為訂單是商品的容器，也只有訂單持有初始化商品的信息，所以這個耦合關(guān)系是正確的且沒辦法避免的，所以由訂單來創(chuàng)建商品。??
3.????? Low coupling (低耦合)
低耦合模式的意思就是要我們盡可能地減少類之間的連接。
其作用非常重要：
a.?????? 低耦合降低了因一個類的變化而影響其他類的范圍。
b.?????? 低耦合使類更容易理解，因為類會變得簡單，更內(nèi)聚。
下面這些情況會造成類A、B之間的耦合：
a.?????? A是B的屬性
b.?????? A調(diào)用B的實例的方法
c.?????? A的方法中引用了B，例如B是A方法的返回值或參數(shù)。
d.?????? A是B的子類，或者A實現(xiàn)了B
關(guān)于低耦合，還有下面一些基本原則：
a.?????? Don’t Talk to Strangers原則：
意思就是說，不需要通信的兩個對象之間，不要進行無謂的連接，連接了就有可能產(chǎn)生問題，不連接就一了百了啦！
b.?????? 如果A已經(jīng)和B有連接，如果分配A的職責給B不合適的話(違反信息專家模式)，那么就把B的職責分配給A。
c.?????? 兩個不同模塊的內(nèi)部類之間不能直接連接，否則必招報應！嘿！
例如：Creator模式的例子里，實際業(yè)務中需要另一個出貨人來清點訂單(Order)上的商品(SKU)，并計算出商品的總價，但是由于訂單和商品之間的耦合已經(jīng)存在了，那么把這個職責分配給訂單更合適，這樣可以降低耦合，以便降低系統(tǒng)的復雜性。如下圖：
?
?????? 這里我們在訂單類里增加了一個TotalPrice()方法來執(zhí)行計算總價的職責，沒有增加不必要的耦合。?
????????????? 4.????? High cohesion (高內(nèi)聚)
高內(nèi)聚的意思是給類盡量分配內(nèi)聚的職責，也可以說成是功能性內(nèi)聚的職責。即功能性緊密相關(guān)的職責應該放在一個類里，并共同完成有限的功能，那么就是高內(nèi)聚合。這樣更有利于類的理解和重用，也便于類的維護。
高內(nèi)聚也可以說是一種隔離，就想人體由很多獨立的細胞組成，大廈由很多磚頭、鋼筋、混凝土組成，每一個部分(類)都有自己獨立的職責和特性，每一個部分內(nèi)部發(fā)生了問題，也不會影響其他部分，因為高內(nèi)聚的對象之間是隔離開的。
例如：一個訂單數(shù)據(jù)存取類(OrderDAO)，訂單即可以保存為Excel模式，也可以保存到數(shù)據(jù)庫中；那么，不同的職責最好由不同的類來實現(xiàn)，這樣才是高內(nèi)聚的設計，如下圖：
?
?????? 這里我們把兩種不同的數(shù)據(jù)存儲功能分別放在了兩個類里來實現(xiàn)，這樣如果未來保存到Excel的功能發(fā)生錯誤，那么就去檢查OrderDAOExcel類就可以了，這樣也使系統(tǒng)更模塊化，方便劃分任務，比如這兩個類就可以分配個不同的人同時進行開發(fā)，這樣也提高了團隊協(xié)作和開發(fā)進度。??
?
5.????? Controller (控制器)
用來接收和處理系統(tǒng)事件的職責，一般應該分配給一個能夠代表整個系統(tǒng)的類，這樣的類通常被命名為“XX處理器”、“XX協(xié)調(diào)器”或者“XX會話”。
關(guān)于控制器類，有如下原則：
a.?????? 系統(tǒng)事件的接收與處理通常由一個高級類來代替。
b.?????? 一個子系統(tǒng)會有很多控制器類，分別處理不同的事務。
關(guān)于這個模式更詳細的論述，請參考《UML和模式應用》第16章。???
?
6.????? Polymorphism (多態(tài))
這里的多態(tài)跟OO三大基本特征之一的“多態(tài)”是一個意思。
例如：我們想設計一個繪圖程序，要支持可以畫不同類型的圖形，我們定義一個抽象類Shape,矩形(Rectangle)、圓形(Round)分別繼承這個抽象類，并重寫(override)Shape類里的Draw()方法，這樣我們就可以使用同樣的接口(Shape抽象類)繪制出不同的圖形，如下圖：
?
這樣的設計更符合高內(nèi)聚和低耦合原則，雖然后來我們又增加了一個菱形(Diamond)類，對整個系統(tǒng)結(jié)構(gòu)也沒有任何影響，只要增加一個繼承Shape的類就行了。??
?
7.????? Pure Fabrication (純虛構(gòu))
這里的純虛構(gòu)跟我們常說的純虛構(gòu)函數(shù)意思相近。高內(nèi)聚低耦合，是系統(tǒng)設計的終極目標，但是內(nèi)聚和耦合永遠都是矛盾對立的。高內(nèi)聚以為這拆分出更多數(shù)量的類，但是對象之間需要協(xié)作來完成任務，這又造成了高耦合，反過來毅然。該如何解決這個矛盾呢，這個時候就需要純虛構(gòu)模式，由一個純虛構(gòu)的類來協(xié)調(diào)內(nèi)聚和耦合，可以在一定程度上解決上述問題。
例如：上面多態(tài)模式的例子，如果我們的繪圖程序需要支持不同的系統(tǒng)，那么因為不同系統(tǒng)的API結(jié)構(gòu)不同，繪圖功能也需要不同的實現(xiàn)方式，那么該如何設計更合適呢？如下圖：
?
這里我們可以看到，因為增加了純虛構(gòu)類AbstractShape，不論是哪個系統(tǒng)都可以通過AbstractShape類來繪制圖形，我們即沒有降低原來的內(nèi)聚性，也沒有增加過多的耦合，可謂魚肉和熊掌兼得，哈哈哈！?
??????? 8.????? Indirection (間接)
“間接”顧名思義，就是這個事不能直接來辦，需要繞個彎才行。繞個彎的好處就是，本來直接會連接在一起的對象彼此隔離開了，一個的變動不會影響另一個。就想我在前面的低耦合模式里說的一樣，“兩個不同模塊的內(nèi)部類之間不能直接連接”，但是我們可以通過中間類來間接連接兩個不同的模塊，這樣對于這兩個模塊來說，他們之間仍然是沒有耦合/依賴關(guān)系的。
?
9.????? Protected Variations (受保護變化)
預先找出不穩(wěn)定的變化點，使用統(tǒng)一的接口封裝起來，如果未來發(fā)生變化的時候，可以通過接口擴展新的功能，而不需要去修改原來舊的實現(xiàn)。也可以把這個模式理解為OCP(開閉原則)原則，就是說一個軟件實體應當對擴展開發(fā)，對修改關(guān)閉。在設計一個模塊的時候，要保證這個模塊可以在不需要被修改的前提下可以得到擴展。這樣做的好處就是通過擴展給系統(tǒng)提供了新的職責，以滿足新的需求，同時又沒有改變系統(tǒng)原來的功能。關(guān)于OCP原則，后面還會有單獨的論述。
?
比設計模式更重要：設計原則
我們生活在一個充滿規(guī)則的世界里，在復雜多變的外表下，萬事萬物都被永恒的真理支配并有規(guī)律的運行著。模式也是一樣，不論那種模式，其背后都潛藏著一些“永恒的真理”，這個真理就是設計原則。記得一次參加微軟的架構(gòu)師培訓，期間講到設計模式，有人問了老師一個問題：“什么東西比設計模式更重要？”，老師是一位有多年豐富實踐經(jīng)驗的開發(fā)者，他毫不猶豫地回答到：“比模式更重要的是原則”。這句話我時常能夠想起，越來越覺得這是一個偉大的答案。的確，還有什么比原則更重要呢？就像人的世界觀和人生觀一樣，那才是支配你一切行為的根本，而對于設計模式來說，為什么這個模式要這樣解決這個問題，而另一個模式要那樣，它們背后都遵循的就是永恒的設計原則。可以說，設計原則是設計模式的靈魂。
對于設計原則的深入探討我還沒有那個深度，推薦大家去看《敏捷軟件開發(fā)—原則、模式與實踐》，下面僅對部分常用的設計原則做些簡單的講解：
?? 1. 單一職責原則(SRP)
?? “就一個類而言，應該僅有一個引起它變化的原因。”也就是說，不要把變化原因各不相同的職責放在一起，因為不同的變化會影響到不相干的職責。再通俗一點地說就是，不該你管的事情你不要管，管好自己的事情就可以了，多管閑事害了自己也害了別人。(當然這里說的多管閑事跟見義勇為是兩回事，我們提倡見義勇為！)
?????? 例如：參考下圖中的設計，圖形計算程序只使用了正方形的Area()方法，永遠不會使用Draw()方法，而它卻跟Draw方法關(guān)聯(lián)了起來。這違反了單一原則，如果未來因為圖形繪制程序?qū)е?/span>Draw()方法產(chǎn)生了變化，那么就會影響到本來毫不關(guān)系的圖形計算程序。
?
????????? ??那么我們該怎么做呢？如下圖，將不同的職責分配給不同的類，使單個類的職責盡量單一，就隔離了變化，這樣他們也不會互相影響了。
?
????????????? 2. 開放—封閉原則(OCP)
? ?“軟件實體(類、模塊、函數(shù)等)應該是可以擴展的，但是不可修改。”嘿！多么樸實的話語，第一次看這個原則的時候我都看傻了，我當時在想“這不是&#%做白日夢嗎！不修改怎么擴展啊？”但是隨著學習的深入，理解了這個“不修改”是什么意思，意思是“你可以隨便增加新的類，但是不要修改原來的類”。從這個角度去理解就好多了，其實這里還是一個隔離變化的問題。
?????? 例如：如下圖，有一個客戶端程序通過數(shù)據(jù)訪問接口操作數(shù)據(jù)，對于這套系統(tǒng)來說，一開始計劃使用的是SQL Server或Oracle數(shù)據(jù)庫，但是后來考慮到成本，改用免費的MySQL；那么對于客戶端程序來說，后來數(shù)據(jù)的擴展對它沒有任何影響，它在不知不覺間就用上了免費好用的MySQL數(shù)據(jù)庫，這全要感謝OCP原則。
?
????? 3. 依賴倒置原則(DIP)
“抽象不應該依賴于細節(jié)。細節(jié)應該依賴于抽象。”關(guān)于這個原則，還有種說法是.“高層不應該依賴于底層，兩者都應該依賴于抽象。”其實怎么說都是對的，關(guān)鍵就是要理解一點，只有抽象的東西才是最穩(wěn)定的，也就是說，我們依賴的是它的穩(wěn)定。如果將來“抽象”也不穩(wěn)定了，那么誰穩(wěn)定我跟誰，其實說白了不就是傍大款嗎！哈哈！
例如：參考下圖的設計，一個開關(guān)跟燈直接連接在一起了，也就是說開關(guān)依賴于燈的打開和關(guān)閉方法，那么如果我想用這個開關(guān)也可以打開其他東西呢，比如電視、音響。顯然這個設計是無法滿足這個要了，因為我們依賴了細節(jié)而不是抽象，這個開關(guān)已經(jīng)等價于“燈的開關(guān)”。
?
?????? 那么我們該如何來設計一個通用的開關(guān)呢？參考下圖的設計，OK！現(xiàn)在我們不僅可以打開燈，還可以打開電視和音響，甚至未來任何實現(xiàn)了“開關(guān)接口”的任何東西。
?
?
???????????? 4. 接口隔離原則(ISP)
“不應該強迫客戶依賴于它們不用的方法。接口屬于客戶，不屬于它所在的類層次結(jié)構(gòu)。”這個說得很明白了，再通俗點說，不要強迫客戶使用它們不用的方法，如果強迫用戶使用它們不使用的方法，那么這些客戶就會面臨由于這些不使用的方法的改變所帶來的改變。
?例如：參考下圖的設計，在這個設計里，取款、存款、轉(zhuǎn)帳都使用一個通用界面接口，也就是說，每一個類都被強迫依賴了另兩個類的接口方法，那么每個類有可能因為另外兩個類的方法(跟自己無關(guān))而被影響。拿取款來說，它根本不關(guān)心“存款操作”和“轉(zhuǎn)帳操作”，可是它卻要受到這兩個方法的變化的影響，真是土鱉！！！
?
????????那么我們該如何解決這個問題呢？參考下圖的設計，為每個類都單獨設計專門的操作接口，使得它們只依賴于它們關(guān)系的方法，這樣就不會互相影響，也就不會在發(fā)生土鱉的事情了！
?
????????????5. 替換原則(LSP)
“子類型必須能夠替換掉它們的基類型。”也就是說繼承中的“IS A”關(guān)系是必須保證的，否則還算什么繼承啊！如果違反了LSP原則，常會導致在運行時(RTTI)的類型判斷違反OCP原則。
例如：函數(shù)A的參數(shù)是基類型，調(diào)用時傳遞的對象是子類型，正常情況下，增加子類型都不會影響到函數(shù)A的，如果違反了LSP，則函數(shù)A必須小心的判斷傳進來的具體類型，否則就會出錯，這就已經(jīng)違反了OCP原則。
關(guān)于模式學習
深刻理解面向?qū)ο笫菍W好設計模式的基礎，掌握一定的面向?qū)ο笤O計原則才能掌握面向?qū)ο笤O計模式的精髓，從而實現(xiàn)靈活運用設計模式。僅知道OO的語言機制是不夠的，懂得語言里的封裝、繼承、多態(tài)，只是滿足了最最基礎的條件，要真正發(fā)揮OO的強大的作用，關(guān)鍵是要深刻理解以上的GRASP模式和設計原則，在此基礎上去再深入理解設計模式，并在實踐中不斷磨練。
模式跟OO原則相比其實并不重要，如果你能設計出基本符合以上原則的程序，那么可能就已經(jīng)總結(jié)出了新的模式，所以學習模式的根本是為了深入理解OO思想和原則，使我們可以寫出高內(nèi)聚低耦合的程序。
另外最近在學習李建忠老師的“C#面向?qū)ο笤O計模式縱橫談系列課程”時候，李老師提出了一個“重構(gòu)到模式”的理論，感覺十分有道理，模式不完全是供我們套用的模版，在特定的業(yè)務環(huán)境下，我們實現(xiàn)的可能只是“類似XX模式”的設計模式，因為針對這個環(huán)境，這么使用就是最合適的，而不是什么時候都必須完全照搬GOF的23種設計模式的格式，模式是死的，而人是活的，找到最合適的實現(xiàn)方式就好，不要為了設計模式而使用設計模式。
作者
王曉亮/Justin
MSN:xiaoliang203@hotmail.com
Mail:xiaoliang.justin@gmail.com
參考資料
《UML和模式應用》
《敏捷軟件開發(fā)—原則、模式與實踐》
李建忠老師的《C#面向?qū)ο笤O計模式縱橫談系列課程》
?
《新程序員》：云原生和全面數(shù)字化實踐50位技術(shù)專家共同創(chuàng)作，文字、視頻、音頻交互閱讀總結(jié)
- 上一篇： A股做新材料的公司 真的很有发展前景
- 下一篇： 惊闻谢文离职雅虎中国