设计原则GRASP(General Responsibility Assignment Software Pattern,通用职责分配模式)

1.创建者Creater

职责：创建另一个类的实例（应该由谁创建对象）

一个类B要创建另一个类A的实例，需要满足以下的一个或者多个条件：

1. B包含了A
2. B记录了A
3. B和A之间的关系密切
4. B拥有A实例化所需要的数据

例：

    汽车类 : Car   
	轮胎类 ：Wheel
	Car是由Wheel聚合而成，则Wheel类由Car创建的；

2.信息专家Information Expert

职责：给一个对象分配职责的一般性原则

把一个职责分配给类A，且类A拥有完成这个职责的所必须的信息，A即信息专家（单一职责原则）

类A对于对于自身的信息Information理解:

1. 有自己的状态数据
2. 知道与自己相关对象的信息
3. 根据已知的信息推导的信息
4. …

3.低耦合Low Coupling

职责：模块之间具有较低的依赖性、一个模块的改变对另一个模块的影响较低、模块的可重用性较高

4.控制器Controller

职责：系统内部第一个解决来自UI层的请求的系统操作，即为控制器Controller

控制器的一般有：

1. 外观控制器（Facade Controller）
2. 用例控制或会话控制器（Use Case or Session Controller )

例：

经典：MVC模式

控制器的现象：

委托模式Delegation Pattern（一个对象A将接收的请求交于B来处理，A只关心处理的结果）

• 外部输入事件可以来自参与者或其它系统

会话控制的命名规范：

< UseCaseName >Handler
< UseCaseName >CoOrdinator
< UseCaseName >Session

5.高内聚High Cohesior

职责：模块内部各元素之间高度的紧密结合，同时保持模块之间的低耦合

一个模块只做一个任务，不要做太多的事件，也是单一职责原则（面向对象的五大原则）。

低的内聚一般有以下原因：

1. 高粒度的抽象
2. 做了太多本应该委托其它类做的事

低内聚的表现：

1. 做了太多无关的事情
2. 做了太多的工作

一个高内聚的类一般有以下特点：

1. 具有较少的数量操作，操作的性质基本一致，不会做太多的事情
2. 若果同类别的工作太多，则会定义新的类分担工作，相互合作

优点：

1. 易于维护
2. 易于理解
3. 易于重用

6.多态Polymorphism

职责：实现处理依据类型不同而产生的不同行为的需求（依据类型变化的行为，进行职责分配）

推论：

1. 不要检测对象的类型或者条件逻辑，并以此选择相应的行为
2. 即，不要使用条件逻辑，而是为不同的类定义相同的名字方法
3. 不同的类实现了相同的接口、或有一个共同的父类

例：

父类：形状

子类：圆、方块、三角形

当需要画自己的时候，只需要调用该方法，不要判断类型去选择画

7.纯虚构Pure Fabrication

职责：减小不同原则之间的矛盾，从而虚构类（可以把高度内聚的职责分配给一个纯虚构的类，从而实现高内聚、低耦合、重用）

例：

• OODB是纯虚构出来的类：用来专门负责数据库的连接

• 其中Account、Customer、Other等不同的类只需要需要实现相应的接口（继承父类），就可以实现相关的数据操作了

8.间接Indirection

职责：职责分配避免两个模块的产生直接耦合，因此把职责分配给一个中介对象（也是可以是虚构出来的对象）

和纯虚构比较像，但出发点不一样。

例

User登陆账号 ------> 数据库连接 DB
可以用一个中间产生一个Server类，减少两者之间的耦合

9.隔离变化Protected Variations

职责：解决系统中不稳定的部分对其它稳定部分产生的意想不到的影响，标识出不稳定的点，职责分配时创建一个稳定的接口，把它们与其余系统分离

变化点分为两种：

1. 变化点：当前系统系统或者当前需求中已经存在了
2. 演化点：推测的类型变化可能在今后，在当前的需求中不存在