GRASP:Designing Objects with Responsibilities
閱讀書上第17章
outputs of object Design
- UML 交互圖、類圖、包圖
- UI草圖和原型
- 數據庫模型
- 報表的草圖和原型
Responsibility-Driven Design
- UML把職責定義爲類元的契約或義務
- 對象的行爲職責
- 自身執行一些行爲，如創建對象或計算
- 初始化其他對象中的動作
- 控制和協調其他對象中的動作
- 對象的認知職責
- 對私有封裝數據的認知
- 對相關對象的認知
- 對其能夠導出或計算的事物的認知
- 準則：
- 領域模型描述了領域對象的屬性和關聯，因此通常產生與“認知”相關的職責
- 大職責具有數百個類和方法，小職責可能只有2個方法
GRASP:
- General Responsibility Assignment Software Patterns
- 繪製交互圖是考慮將職責實現爲方法的時機
-
模式：以結構化形式對這些問題、解決方法和命名進行描述使其系統化，那麼這些原則和習慣用法稱爲模式
- Creator:誰應該負責創建類的實例
- 如果以下條件之一爲真，將創建A的實例的職責分配給類B
- B包含或組成聚集了A
- B記錄了A
- B直接使用A
- B具有A的初始化數據
- 好處：
- 支持 low coupling，減少維護的依賴性和增加重用的可能性
- 準則：
- 封裝的容器和記錄類是創建其所容納和事物的很好的選擇
- Information Expert：如果給定鍵值，誰知道對象的相關信息
- 把職責分配給具有完成該職責所需信息的那個類
- 好處：
- 信息封裝，支持低耦合
- 鼓勵鏈接使用更多易於理解和維護的輕量級類定義
- Low Coupling：如何減少因變化產生的影響
- 分配職責以使（不必要的）耦合保持在較低的水平
- coupling：元素與其他元素的連接、感知及依賴的程度的度量
- 在面嚮對象語言中，以下情況X有對Y的耦合
- X有Y實例/Y類的屬性
- X對象調用Y對象的函數
- X有一個方法涉及到Y實例/Y類，如Y的參數或者局部變量或X方法返回一個Y實例
- X是Y的直接/間接子類，子類和超類之間有很強的耦合性
- Y是接口，X是實現
- 好處
- 不會被其他組件的改變所影響
- 便於理解
- 易於複用
- 高耦合本身不是問題所在，而是和不穩定的元素之間的耦合
- Controller：在UI層上的哪個對象應該首先從UI層接收該消息
- 控制器：UI層外第一個負責接收並處理系統操作信息的對象
- 把職責分配給能代表下列選擇之一的對象：
- 外觀控制器：代表全部“系統”、“根對象”、運行軟件的設備或主要的子系統，外觀控制器的所有變形
- 用例控制器：代表發生系統操作的用例場景
- 準則
- 控制器應當把需要完成的工作委派給其他對象。控制器只是協調或控制這些活動，本身並不完成大量工作
- 概念
- entity object： 與應用無關的（一般是持久性的）領域軟件對象
- boundary object： 接口的抽象
- control object：控制器模式描述的用例處理者
- 優點
- 增加了可複用和接口可拔插的潛力
- 獲得了推測用例狀態的機會
- 臃腫的控制器
- 跡象
- 只有一個控制器類來接收系統中全部的系統事件，而且有很多系統事件
- 爲了處理系統時間，由控制器完成諸多必要的任務，而不是把工作委派出去
- 控制器有很多屬性並且他維護關於系統或領域的重要信息，（這些職責本應分配給其他對象）或者他要複製在其他地方纔能找到的信息
- 解決方案
- 增加控制器
- 設計控制器，是他吧完成每個系統操作的職責委派給其他對象
- High Cohesion：怎樣使對象保持有內聚、可理解和可管理，同時具有支持低耦合的附加作用
- 低內聚意味着對象僅靠本身工作，並且需要和大量其他對象進行協作，所有交互也都趨向高耦合
- 優點
- 能夠更加輕鬆、清楚地理解設計
- 簡化維護和改進工作
- 通常支持低耦合
- 由於內聚的類可以用於某個特定目的，因此細粒度、相關性強的功能的重要性增強