GRASP
General Responsibility Assignment Software Patterns:通用职责分配软件设计，它可以帮助设计人员理解面向对象设计的本质，并以一种有条理的,理性的,可解释的方式来运用这些原则。
两个例子的类图
POS(Point of Sale):超市的收银机
Monopoly（大富翁游戏）
GRASP原则一:创建者 Creator
问题
谁来负责创建类的实例
解决办法
满足下面一个选项,则由B来创建A
1 B包含,聚集A
2 B 记录A
3 B 紧密使用 A
4 B 拥有A的初始化数据
若以上有多个选项使用,则首选包含或聚集的类
注:A和B都是软件对象。
何时不使用?
1 重用类的实例目的性能或缓存
2 委托职责向下传递
3 其他复杂情况
好处
高内聚
低耦合
例子
在大富翁游戏中,谁来创建Square?
由Board来创建Square，因为Board是Square的聚集
GRASP原则二:信息专家 Information Expert
问题
分配职责的一般性原则是什么？
解决办法
若这个类拥有完成这个职责所需要的数据,则把这个职责分配给这个类
优点
封装性:对象充分利用自身的信息，低耦合
系统行为分布到不同的类:高内聚
示例
Who should know the grand total (总计) of a sale?
Sale拥有计算总额的所有数据,所以把这个职责分配给Sale
GRASP原则三: 低耦合 Low Coupling
耦合
1 耦合的定义
一个元素和另一个元素的连接，感知和依赖程度
2 比较
内聚:模块内的元素之间紧密程度，如一个类内部操作之间
耦合:两个子模块之间的紧密程度
3 X与Y存在耦合的情况，例如
X拥有Y的属性
X有Y的成员变量,方法参数和局部变量
X是Y的子类
X是接口,Y是实现
问题
怎样解决低依赖性,低变化影响和增加复用
解决办法
分配职责后仍然保持低耦合。
原则
1 低耦合是不具有可操作性性,是一个评估原则,如若两个方案都可以的,倾向于选择低耦合的方案。如能用组合的不要用继承
2 类之间存在适当的耦合是必须的,正常的。因为只有这样才产生面向对象系统,任务才能通过对象间的相互协作来完成
3 极端情况:类之间没有耦合:这样会形成一个很差的设计,一个类来完成全部的工作。
何时不使用?
若是稳定的或广为流传的,可以才有高耦合如java的jdk，软件系统可以和jdk高耦合。
实例
在pos系统中,谁来创建 Payment?
因为方案2没有Register和Payment的关系,耦合度低一些，所以方案2会更好一些。
GRASP原则四：控制器 Controller
问题
在领域层，由谁负责首先接收并协调来自UI层的系统操作？
解决办法
1 Facade(外观) Controller：代表整个系统的对象,如一个根对象，一个系统运行的设备或一个主要的子系统。
2 Use Case or Session Controller（用例控制器、会话控制器）：一类系统事件
会话控制器的命名习惯
<UseCaseName> Handler or <UseCaseName> CoOrdinator or <UseCaseName>Session
优点
容易适应UI层的变化
领域层代码易于重用
臃肿控制器的解决办法
增加更多的控制器
采用会话控制器替换外观控制器
控制器委托任务给别的对象，而不是自己做
高内聚的理念
GRASP原则五：高内聚 High Cohesion
问题
如何使对象功能专注、可理解、可管理，同时又支持低耦合
解决办法
分配职责时保证高内聚
用法
用作评价工具,更多的是一种理念,没有具体的可操作原则。
内聚的最佳实践
1 一个类完成的功能不要太多，且这些功能都是同级别的。例如:教授的主要功能是教学,研究员的主要工作是科研。
2 如果同类别的工作太多，则会定义新的类分担任务，相互间合作
比喻”不是一家人,不进一家门”
“人”指的是操作,职责，”门”指的是模块，类
类低内聚
1 症状
做了太多相互无关的工作：不是你的职责你做了
做了太多工作：是你的职责，但做的事情太多了，需要把职责在细分
2 原因
大粒度的抽象：如打扫卫生可以分为扫地，擦黑板等。
做了太多本应该委托给其他类去做的工作
3 缺点
难以理解：因为职责太多，太复杂。
难以重用：耦合度太高
没有稳定的时刻，总是在修改 (通常都会高耦合)
