基于職責設計對象
最關鍵的軟件開發工具是受過良好設計原則訓練的思維，而不是UML或其他任何技術。

RDD是思考OO軟件設計的一般性隱喻。把軟件對象想象成具有某種職責的人，他要與其他人協作以完成工作。RDD使我們把OO設計看作是有職責對象進行協作的共同體。

分配職責的基本模式是GRASP。

創建者模式
  問題：誰創建類A的實例？
  建議：如果以下條件為真時（越多越好），將創建類A實例的職責分配給類B：
        1、B“包含”或組成聚集了A。
        2、B記錄A。
        3、B緊密的使用A。
        4、B具有A的初始化數據。
        首選聚集或包含A的類B。
  注意：A和B指的都是軟件對象而不是領域模型對象。
  禁忌：對象的創建常常具有相當的復雜性。在一些情況下，更適合使用工廠。

信息專家模式
  問題：給對象分配職責的基本原則是什么？
  建議：把職責分配給具有完成該職責所需信息的那個類。把職責和數據置于一處，把服務與其屬性置于一處。
  禁忌：相比較而言系統關注更為重要，設計要分離主要的系統關注。例如：領域對象加入持久化邏輯成為充血模型，這就把應用邏輯與數據庫邏輯混合起來了（不良設計）。

低耦合模式
  問題：如何減少因變化產生的影響？（高耦合并不是問題所在，問題是與某些方面不穩定的元素之間的高耦合）
  建議：分配職責以使（不必要的）耦合保持在較低的水平。（信息專家模式支持低耦合）

控制器模式
  問題：在UI層之上首先接受和協調系統操作的對象是什么？
  建議：把職責分配給能代表下列選擇之一的對象：
        1、代表全部“系統”、“根對象”、運行軟件的設備或主要的子系統（外觀控制器的變體）。
        2、代表發送系統操作的用例場景（用例或會話控制器）。

高內聚模式
  問題：怎樣使對象保持有內聚、可理解和可管理，同時具有支持低耦合的附加作用？
  建議：職責分配應保持高內聚。委派職責。內聚性低的類通常表示大粒度的抽象，或承擔了本該委托給其他對象的職責。

多態模式
  問題：如何處理基于類型的選擇？如何創建可插拔的軟件構件？
  建議：當相關選擇或行為隨類型（類）有所不同時，使用多態為變化的行為類型分配職責。不要測試對象的類型，也不要使用條件邏輯來執行基于類型的不同選擇。
  經驗：如果有一個具有抽象超類C1的類層次結構，可以考慮對應于C1中的公共方法特征標記來定義接口I1，然后聲明C1來實現接口I1。

純虛構模式
  問題：當并不想違背高內聚和低耦合或其他目標，但基于專家模式的方案又不合適時，哪些對象應承擔這一職責？
  建議：人為制造類，由該類來承擔一組高內聚的職責。該類并不代表問題領域的概念-是虛構的事物。例如DAO
  純虛構通常基于相關的功能性進行劃分，因此這是一種以功能為中心的對象。

間接性模式
  問題：為了避免兩個或多個事物之間的直接耦合，應該如何分配職責？
  建議：將職責分配給中介對象。例如，Adapter
  間接性的動機通常是為了低耦合，并且大多數間接性中介都是純虛構的。

防止變異模式
  問題：如何設計對象、子系統和系統，使其內部的變化或不穩定性不會對其他元素產生不良影響？
  建議：創建穩定的接口。
  不要和陌生人講話：約束了應該在方法里給哪些對象發送消息。它要求在方法里，只應給以下對象發送消息：
  1、this對象（自身）
  2、方法的參數
  3、this的屬性
  4、作為this屬性的集合中的元素
  5、在方法中創建的對象
  典型違反該原則的例子： F f=foo.getA().getB().getC().getD().getE().getF();

命令-查詢分離原則：
  執行動作（更新、調整，等等）的命令方法，這種方法通常具有改變對象狀態等副作用，并且是void的（沒有返回值）。
  向調用者返回數據的查詢，這種方法沒有副作用，不會永久性地改變任何對象的狀態。
關鍵在于：一個方法不應該同時屬于以上兩種類型。
 
在繪制交互圖時考慮和決定職責分配。然后在類圖的方法分欄里概括職責分配結果，方法是職責的具體實現。


http://www.tkk7.com/ronghao 榮浩原創，轉載請注明出處：）