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：怎样使对象保持有内聚、可理解和可管理，同时具备支持低耦合的附加做用
  • 低内聚意味着对象仅靠自己工做，而且须要和大量其余对象进行协做，全部交互也都趋向高耦合
  • 优势
    • 可以更加轻松、清楚地理解设计
    • 简化维护和改进工做
    • 一般支持低耦合
    • 因为内聚的类能够用于某个特定目的，所以细粒度、相关性强的功能的重要性加强