P3_C17：設計對象的原則

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：怎樣使對象保持有內聚、可理解和可管理，同時具備支持低耦合的附加做用
  • 低內聚意味着對象僅靠自己工做，而且須要和大量其餘對象進行協做，全部交互也都趨向高耦合
  • 優勢
    • 可以更加輕鬆、清楚地理解設計
    • 簡化維護和改進工做
    • 一般支持低耦合
    • 因爲內聚的類能夠用於某個特定目的，所以細粒度、相關性強的功能的重要性加強