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