（原創）一個優秀軟件開發人員的必修課：GRASP軟件開發模式淺析
關鍵字: grasp java 軟件模式你是一個優秀軟件開發人員嗎？你知道GRASP嗎？GRASP軟件開發模式，全稱通用職責分配軟件模式（General Responsibility Assignment Software Patterns），是與著名的軟件模式GoF（Gang of Four，即我們常說的那23種軟件開發模式）齊名的另一種軟件開發模式。但是與GoF不同的是，它並不是提出一些具體的軟件組織結構，而是提出，在將現實世界的業務功能抽象成軟件開發中具體對象的過程中，我們應當遵循的一些基本原則。遵循這些基本原則，我們纔可以開發出高質量的軟件出來。對於我們要開發的軟件項目，我們可以不使用工廠模式、可以不使用單例模式、我們也可以不使用觀察者模式，但是我們不可能不將現實世界的業務功能抽象成軟件開發中具體對象。從這個角度說，我們要提高自己的軟件開發質量，深入理解GRASP比深入理解GoF更重要。但是我看到現在介紹GoF的文章多，介紹GRASP文章少。正因爲如此，我現在把GRASP介紹給大家。
一.職責分配和職責驅動設計
在一個軟件項目開始的時候，我們通常需要進行需求分析，瞭解客戶需要設計一個什麼樣的軟件，這個軟件中應當有什麼功能。需求分析瞭解到的是現實世界中客戶需求的業務功能，每個業務功能往往是一個業務流程，即客戶在日常工作中不斷在完成的業務流程。同時，在用戶的問題世界中，必然有一些東西或者說事物，它們之間存在着相互的關聯。
拿一個軟件評審管理系統作爲一個例子吧。評審管理系統的業務需求如下：
1．評審組織者制訂評審計劃，提交領導審批，然後通過郵件通知評審者。
2．評審者接到通知，分別對評審對象進行評審，填寫評審表，並可以對評審對象提出疑問。
3．評審組織者彙總評審者的疑問，召開評審會議討論這些疑問。在會上，有些疑問變爲問題，有些疑問不是問題，有些則依然不能夠確認。
4．會後，評審組織者整理疑問，形成評審報告，然後由評審者分別表決該評審是否通過。最後評審組織者彙總表決結果，形成評審結論。
5．評審組織者跟蹤問題的解決。
通過以上需求的描述，我們不難發現整個問題世界中的相關事物：評審組織者、評審計劃、評審者、評審對象、評審表、疑問、評審報告、評審結論、問題。我們也不難分析出這些事物相互關係，比如評審計劃與評審者是一對多，而評審報告與評審結論是一對一。
在RUP中，業務需求將形成用例模型及其描述文檔中的用例，事物及其關係將形成領域模型中的對象，當然如何製作用例模型和領域模型超出了本文討論的範圍，有興趣的朋友可以看看相關文章。
領域模型中的對象將成爲軟件開發中形成具體對象的基礎（軟件開發中形成什麼對象是根據軟件開發的具體需求而定的，並不一定要與領域模型的對象一致）。用例模型中的用例，將通過賦予這些對象行爲而得以實現。現在的問題就出來了，用例模型中的功能，或者說一系列行爲，應當如何分配給這些對象呢。也就是說，爲了完成同一個任務，我可以將行爲A交給對象X，也可以交給對象Y。雖然交給對象X與交給對象Y，我對行爲A的具體實現不一樣，但是都可以完成行爲A的任務。那麼，我到底應當交給對象X還是對象Y呢？有沒有一個基本原則呢？有，那就是按照職責分配任務。雖然從理論上說，我可以任意定義對象，可以讓對象沒有任何意義，或者去完成任意的工作，但是通常我們不會這樣去設計。通常我們會將對象與現實世界的對象聯繫起來，比如設計一個評審計劃對象、評審者對象。並且我們在設計對象的時候應當做到“低表示差異”。低表示差異就是我們設計的對象應當與現實世界的對象儘量一致。比如說我們設計一個對象叫“評審者”，是因爲我們在現實世界中有評審者。同時，我們爲評審者對象賦予的行爲也應當儘量與現實世界一致，比如增加評審者、修改評審者、得到評審者信息。那麼哪些是這個對象應當賦予的行爲呢，這應當由職責來決定。
我們通過對現實世界的分析，或者說對於領域模型的分析，設計出了軟件系統中的對象，這時候我們應當爲每一個對象分配職責。什麼是對象的職責呢，當然是通過對現實世界的分析，定義的這個對象應當完成的任務。比如評審者對象的職責是存取與評審者相關的數據。當然對象的職責不一定是一個，比如評審計劃包含了評審對象和評審者的子項，所以它在工作不繁忙的情況下可以代理處理評審對象和評審者的信息存取。但是一個對象的職責不應當過多（也就2、3個就行了）並且高度相關。比如評審表對象如果分配職責處理評審表的同時，又去處理評審計劃的數據，這就叫職責無關。
職責分配現在已經被普遍認爲是一個優秀的軟件設計應當遵循的原則，它有以下好處：
1．低表示差異使軟件結構清晰，易於理解，因爲軟件開發並不是一個人的事情。在多人共同開發的軟件項目中，一目瞭然的軟件結構可以避免開發人員因誤解而造成的不必要錯誤。
2．易於維護和變更。假如評審計劃出了問題或需要修改，我們就去找評審計劃，如果是評審者的問題我們就去找評審者，而絕對不會與其它對象有關。
這種通過考慮對象、職責、協作的對象設計及構件方式，被稱爲“職責驅動設計（RDD，Responsibility Drive Design）”。職責驅動設計是通過先設計用例模型、用例模型描述、操作契約、系統順序圖、領域模型、詞彙表，再一步步製作分析模型、設計模型，寫出每個功能的交互圖、類圖的很複雜的過程，我在這裏就不再詳述了。但是請大家注意一個非常重要的細節，前面我們說，軟件系統中的對象是根據現實世界抽象得到，對象職責的分配是根據對象的定義，分配一些不多並且高度相關的任務。然而我們即使遵照這些原則，也有相當大的設計彈性空間，不同人根據自己的理解，對於同一個功能依然有各自不同的設計。GRASP中文譯爲“通用職責分配軟件模式”，就是對對象分析和設計中職責分配問題提出數個基本原則。同時，這幾個基本原則也應當掌握一個度，即並不是所有情況下都適用，也不是一個絕對的指標。比如低耦合，並不是絕對的不耦合，不耦合軟件就沒法設計了；高內聚也不能無限度地高內聚，否則系統就繁複異常了。
二.GRASP模式挨個析
GRASP軟件設計模式包括9個模式：創建者、信息專家、低耦合、控制器、高內聚、多態性、純虛構、間接性、防止變異。
（原創）一個優秀軟件開發人員的必修課：GRASP（2）低耦合
（原創）一個優秀軟件開發人員的必修課：GRASP（3）高內聚
一個對象撕心裂肺的怒吼：誰來創建我！GRASP（4）創建者模式
（待續）