要學習設計模式，有些基礎知識是我們必須要先知道的，設計模式是關於類和物件的一種高效、靈活的使用方式，也就是說，必須先有類和物件，才能有設計模式的用武之地，否則一切都是空談，那麼類和物件是從那冒出來的呢？這時就需要比23種設計模式更重要更經典的GRASP模式登場了，嘿嘿，原來這才是老大！

GRASP(General Responsibility Assignment Software Patterns)，中文名稱為“通用職責分配軟體模式”，GRASP一共包括9種模式，它們描述了物件設計和職責分配的基本原則。也就是說，如何把現實世界的業務功能抽象成物件，如何決定一個系統有多少物件，每個物件都包括什麼職責，GRASP模式給出了最基本的指導原則。初學者應該儘快掌握、理解這些原則，因為這是如何設計一個面向物件系統的基礎。可以說，

1.Information Expert (資訊專家)

資訊專家模式是面向物件設計的最基本原則，是我們平時使用最多，應該跟我們的思想融為一體的原則。也就是說，我們設計物件(類)的時候，如果某個類擁有完成某個職責所需要的所有資訊，那麼這個職責就應該分配給這個類來實現。這時，這個類就是相對於這個職責的資訊專家。

例如：常見的網上商店裡的購物車(ShopCar),需要讓每種商品(SKU)只在購物車內出現一次，購買相同商品，只需要更新商品的數量即可。如下圖：

(SKUID)來唯一區分商品，而商品編號是唯一存在於商品類裡的，所以根據資訊專家模式，應該把比較商品是否相同的方法放在商品類裡。 

2.Creator (創造者)

實際應用中，符合下列任一條件的時候，都應該由類Ａ來建立類Ｂ，這時Ａ是Ｂ的建立者：

a.Ａ是Ｂ的聚合

b.Ａ是Ｂ的容器

c.Ａ持有初始化Ｂ的資訊(資料)

d.Ａ記錄Ｂ的例項

e.Ａ頻繁使用Ｂ

如果一個類建立了另一個類，那麼這兩個類之間就有了耦合，也可以說產生了依賴關係。依賴或耦合本身是沒有錯誤的，但是它們帶來的問題就是在以後的維護中會產生連鎖反應，而必要的耦合是逃不掉的，我們能做的就是正確地建立耦合關係，不要隨便建立類之間的依賴關係，那麼該如何去做呢？就是要遵守建立者模式規定的基本原則，凡是不符合以上條件的情況，都不能隨便用A建立B。

例如：因為訂單(Order)是商品(SKU)的容器，所以應該由訂單來建立商品。如下圖：

3.Low coupling (低耦合)

低耦合模式的意思就是要我們儘可能地減少類之間的連線。

其作用非常重要：

a.低耦合降低了因一個類的變化而影響其他類的範圍。

b.低耦合使類更容易理解，因為類會變得簡單，更內聚。

下面這些情況會造成類A、B之間的耦合：

a.A是B的屬性

b.A呼叫B的例項的方法

c.A的方法中引用了B，例如B是A方法的返回值或引數。

d.A是B的子類，或者A實現了B

關於低耦合，還有下面一些基本原則：

a.Don’t Talk to Strangers原則：

意思就是說，不需要通訊的兩個物件之間，不要進行無謂的連線，連線了就有可能產生問題，不連線就一了百了啦！

b.如果A已經和B有連線，如果分配A的職責給B不合適的話(違反資訊專家模式)，那麼就把B的職責分配給A。

c.兩個不同模組的內部類之間不能直接連線，否則必招報應！嘿！

例如：Creator模式的例子裡，實際業務中需要另一個出貨人來清點訂單(Order)上的商品(SKU)，並計算出商品的總價，但是由於訂單和商品之間的耦合已經存在了，那麼把這個職責分配給訂單更合適，這樣可以降低耦合，以便降低系統的複雜性。如下圖：

TotalPrice()方法來執行計算總價的職責，沒有增加不必要的耦合。

      4.High cohesion (高內聚)

高內聚的意思是給類儘量分配內聚的職責，也可以說成是功能性內聚的職責。即功能性緊密相關的職責應該放在一個類裡，並共同完成有限的功能，那麼就是高內聚合。這樣更有利於類的理解和重用，也便於類的維護。

高內聚也可以說是一種隔離，就想人體由很多獨立的細胞組成，大廈由很多磚頭、鋼筋、混凝土組成，每一個部分(類)都有自己獨立的職責和特性，每一個部分內部發生了問題，也不會影響其他部分，因為高內聚的物件之間是隔離開的。

例如：一個訂單資料存取類(OrderDAO)，訂單即可以儲存為Excel模式，也可以儲存到資料庫中；那麼，不同的職責最好由不同的類來實現，這樣才是高內聚的設計，如下圖：

Excel的功能發生錯誤，那麼就去檢查OrderDAOExcel類就可以了，這樣也使系統更模組化，方便劃分任務，比如這兩個類就可以分配個不同的人同時進行開發，這樣也提高了團隊協作和開發進度。  

5.Controller (控制器)

用來接收和處理系統事件的職責，一般應該分配給一個能夠代表整個系統的類，這樣的類通常被命名為“XX處理器”、“XX協調器”或者“XX會話”。

關於控制器類，有如下原則：

a.系統事件的接收與處理通常由一個高階類來代替。

b.一個子系統會有很多控制器類，分別處理不同的事務。

關於這個模式更詳細的論述，請參考《UML和模式應用》第16章。

6.Polymorphism (多型)

這裡的多型跟OO三大基本特徵之一的“多型”是一個意思。

例如：我們想設計一個繪圖程式，要支援可以畫不同型別的圖形，我們定義一個抽象類Shape,矩形(Rectangle)、圓形(Round)分別繼承這個抽象類，並重寫(override)Shape類裡的Draw()方法，這樣我們就可以使用同樣的介面(Shape抽象類)繪製出不同的圖形，如下圖：

(Diamond)類，對整個系統結構也沒有任何影響，只要增加一個繼承Shape的類就行了。  

7.Pure Fabrication (純虛構)

這裡的純虛構跟我們常說的純虛構函式意思相近。高內聚低耦合，是系統設計的終極目標，但是內聚和耦合永遠都是矛盾對立的。高內聚以為這拆分出更多數量的類，但是物件之間需要協作來完成任務，這又造成了高耦合，反過來毅然。該如何解決這個矛盾呢，這個時候就需要純虛構模式，由一個純虛構的類來協調內聚和耦合，可以在一定程度上解決上述問題。

例如：上面多型模式的例子，如果我們的繪圖程式需要支援不同的系統，那麼因為不同系統的API結構不同，繪圖功能也需要不同的實現方式，那麼該如何設計更合適呢？如下圖：

AbstractShape，不論是哪個系統都可以通過AbstractShape類來繪製圖形，我們即沒有降低原來的內聚性，也沒有增加過多的耦合，可謂魚肉和熊掌兼得，哈哈哈！

      8.Indirection (間接)

“間接”顧名思義，就是這個事不能直接來辦，需要繞個彎才行。繞個彎的好處就是，本來直接會連線在一起的物件彼此隔離開了，一個的變動不會影響另一個。就想我在前面的低耦合模式裡說的一樣，“兩個不同模組的內部類之間不能直接連線”，但是我們可以通過中間類來間接連線兩個不同的模組，這樣對於這兩個模組來說，他們之間仍然是沒有耦合/依賴關係的。

9.Protected Variations (受保護變化)

預先找出不穩定的變化點，使用統一的介面封裝起來，如果未來發生變化的時候，可以通過介面擴充套件新的功能，而不需要去修改原來舊的實現。也可以把這個模式理解為OCP(開閉原則)原則，就是說一個軟體實體應當對擴充套件開發，對修改關閉。在設計一個模組的時候，要保證這個模組可以在不需要被修改的前提下可以得到擴充套件。這樣做的好處就是通過擴充套件給系統提供了新的職責，以滿足新的需求，同時又沒有改變系統原來的功能。關於OCP原則，後面還會有單獨的論述。

這裡我們可以看到，因為增加了純虛構類

這樣的設計更符合高內聚和低耦合原則，雖然後來我們又增加了一個菱形

 這裡我們把兩種不同的資料儲存功能分別放在了兩個類裡來實現，這樣如果未來儲存到

這裡我們在訂單類裡增加了一個

這裡因為訂單是商品的容器，也只有訂單持有初始化商品的資訊，所以這個耦合關係是正確的且沒辦法避免的，所以由訂單來建立商品。

針對這個問題需要權衡的是，比較商品是否相同的方法需要放到那裡類裡來實現呢？分析業務得知需要根據商品的編號

我們生活在一個充滿規則的世界裡，在複雜多變的外表下，萬事萬物都被永恆的真理支配並有規律的執行著。模式也是一樣，不論那種模式，其背後都潛藏著一些“永恆的真理”，這個真理就是設計原則。記得一次參加微軟的架構師培訓，期間講到設計模式，有人問了老師一個問題：“什麼東西比設計模式更重要？”，老師是一位有多年豐富實踐經驗的開發者，他毫不猶豫地回答到：“比模式更重要的是原則”。這句話我時常能夠想起，越來越覺得這是一個偉大的答案。的確，還有什麼比原則更重要呢？就像人的世界觀和人生觀一樣，那才是支配你一切行為的根本，而對於設計模式來說，為什麼這個模式要這樣解決這個問題，而另一個模式要那樣，它們背後都遵循的就是永恆的設計原則。可以說，設計原則是設計模式的靈魂。

對於設計原則的深入探討我還沒有那個深度，推薦大家去看《敏捷軟體開發—原則、模式與實踐》，下面僅對部分常用的設計原則做些簡單的講解：

   1. 單一職責原則(SRP)

   “就一個類而言，應該僅有一個引起它變化的原因。”也就是說，不要把變化原因各不相同的職責放在一起，因為不同的變化會影響到不相干的職責。再通俗一點地說就是，不該你管的事情你不要管，管好自己的事情就可以了，多管閒事害了自己也害了別人。(當然這裡說的多管閒事跟見義勇為是兩回事，我們提倡見義勇為！)

例如：參考下圖中的設計，圖形計算程式只使用了正方形的Area()方法，永遠不會使用Draw()方法，而它卻跟Draw方法關聯了起來。這違反了單一原則，如果未來因為圖形繪製程式導致Draw()方法產生了變化，那麼就會影響到本來毫不關係的圖形計算程式。

        那麼我們該怎麼做呢？如下圖，將不同的職責分配給不同的類，使單個類的職責儘量單一，就隔離了變化，這樣他們也不會互相影響了。