基于職責(zé)設(shè)計對象
最關(guān)鍵的軟件開發(fā)工具是受過良好設(shè)計原則訓(xùn)練的思維，而不是UML或其他任何技術(shù)。

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

分配職責(zé)的基本模式是GRASP。

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

信息專家模式
  問題：給對象分配職責(zé)的基本原則是什么？
  建議：把職責(zé)分配給具有完成該職責(zé)所需信息的那個類。把職責(zé)和數(shù)據(jù)置于一處，把服務(wù)與其屬性置于一處。
  禁忌：相比較而言系統(tǒng)關(guān)注更為重要，設(shè)計要分離主要的系統(tǒng)關(guān)注。例如：領(lǐng)域?qū)ο蠹尤氤志没壿嫵蔀槌溲Ｐ停@就把應(yīng)用邏輯與數(shù)據(jù)庫邏輯混合起來了（不良設(shè)計）。

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

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

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

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

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

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

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

命令-查詢分離原則：
  執(zhí)行動作（更新、調(diào)整，等等）的命令方法，這種方法通常具有改變對象狀態(tài)等副作用，并且是void的（沒有返回值）。
  向調(diào)用者返回數(shù)據(jù)的查詢，這種方法沒有副作用，不會永久性地改變?nèi)魏螌ο蟮臓顟B(tài)。
關(guān)鍵在于：一個方法不應(yīng)該同時屬于以上兩種類型。
 
在繪制交互圖時考慮和決定職責(zé)分配。然后在類圖的方法分欄里概括職責(zé)分配結(jié)果，方法是職責(zé)的具體實現(xiàn)。


http://www.tkk7.com/ronghao 榮浩原創(chuàng)，轉(zhuǎn)載請注明出處：）