[软件工程] GRASP设计模式

GRASP 设计模式

---

---

1. 创建者(Creator)

问题：谁应该负责创建一个类的新实例？

解决方案：如果满足以下条件之一，则将创建类A实例的职责交给类B（B创建A）。

• B包含或组成聚集A
• B记录A
• B直接使用A
• B具有A的初始化数据，并在创建A时，将这些数据传给A

如果有多个类B满足以上条件，一般首选，包含或组成聚集类A的B。

优点：

1. 支持低耦合， 因为A本身对于其创建者B就是可见的（即本身就有关联）所以不会增加耦合性

相关模式：

1. 低耦合
2. 具体工厂和抽象工厂
3. 整体-部分

2. 信息专家(Information Expert)

问题：给对象分配职责的基本原则是什么？

解决方案：将职责分配给信息专家（如果一个类拥有完成某个职责的所有信息，那么他就是这个职责的信息专家）。完成一个职责往往需要不同类中的信息，所以这些局部的信息专家可能需要协作来完成一个职责。

对象的职责：

1. 行为职责：
   
   • 自身执行一些行为，如创建对象和计算。
   • 初始化其他对象中的动作。
   • 控制和协调其他对象中的活动。
2. 认知职责：
   
   • 对私有封装数据的认知。
   • 对相关对象的认知。
   • 对其能够导出或计算出事物的认知。

优点：

1. 支持低耦合，因为对象使用自身信息完成任务，所以支持了低耦合

相关模式：

1. 低耦合
2. 高内聚

3. 低耦合(Low Coupling)

耦合的定义： 耦合是对某元素与其他元素之间的连接，感知和依赖程度的度量。低耦合意味着类不会过度依赖其他类。

问题： 怎样降低依赖性，减少变化带来的影响，提高重用性？

解决方案： 分配职责。

下面这些情况会造成类A、B之间的耦合：

• A是B的属性
• A调用B的实例的方法
• A的方法中引用了B，例如B是A方法的返回值或参数。
• A是B的子类，或者A实现了B

优点：

1. 不受其他构件变化的影响。
2. 易于单独理解。
3. 便于复用。

相关模式：

1. 防止变异

4. 控制器(Controller)

问题：在UI层之上首先接收和协调系统操作的第一个对象是什么？

解决方案：把职责分配给以下类

1. 代表整个系统，根对象，运行软件的设备或主要系统。
2. 代表用例场景，在该场景中发生系统事件。

控制器是UI层之上的第一个对象，他负责接收和处理系统操作信息。

准则：正常情况下，控制器应该把需要完成的工作委派给其他的对象。控制器只是协调或控制这些活动，本身并不完成大量工作。

优点：

1. 提供了可复用和接口可插拔的潜力。

相关模式：

1. 命令
2. 外观
3. 层
4. 纯虚构

5. 高内聚(High Cohesion)

内聚的定义：内聚是对元素职责相关性和集中度的度量。如果元素具有高度相关的职责，而且没有过多的工作，那么该元素具有高内聚性。

问题：怎样保证对象是有重点的，可理解的，可管理的，并且能够支持低耦合。

解决方案：分配职责，内聚性较低的类要完成许多不相关的职责，需要完成大量的工作，所以是不合理的。

优点：

1. 简化了维护和改进的工作
2. 通常支持低耦合
3. 相关功能重用性增强

相关模式：

1. 低耦合

6. 多态性(Polymorphism)

问题：如何处理基于类型的选择？如何创建可插拔的软件构件？

1. 基于类型的选择：如果使用 if-else 来处理系统的变化，那么当出现变化时，需要修改这些遍布程序各处的case。
2. 可插拔软件构件：如何替换服务器中的构件而不对客户端形成影响。

优点：

1. 易于新变化所需要的扩展
2. 无需影响客户便能够引入新的实现

相关模式：

1. 防止变异

7. 纯虚构(Pure Fabrication)

问题：当你并不想违背高内聚和低耦合或其他目标，但是基于专家模式所提供的方案又不适合时，哪些对象承担这一职责？

解决方案：创建一个凭空虚构的类，并为它分配职责。

优点：

1. 支持高内聚
2. 增加可复用性

相关模式：

1. 低耦合
2. 高内聚
3. 信息专家

8. 间接性(Indirection)

问题：为了避免两个或多个事物之间直接耦合，应该如何分配职责？

解决方案：将职责分配给中介对象，使其作为媒介。

优点:

1. 支持了低耦合

相关模式：

1. 低耦合
2. 防止变异
3. 纯虚构

9. 防止变异(Protected Variations)

问题：如何设计对象，子系统和系统，使其内部的变化和不稳定性不会对其他元素产生不良影响。

解决方案：识别预计变化或不稳定之处，并在这些变化之外创建接口。

不要说话准则：在方法中，只应该给以下对象发送消息

• this对象（自身）
• 方法的参数
• this的属性
• 作为this属性的集合中的元素
• 在方法中创建的对象

两种变化方法：

1. 变化点：现有、当前系统或需求中的变化
2. 进化点：预测将来可能会产生的变化点，但并不存在于现有需求中

优点：

1. 易于增加新变化所需的扩展
2. 可以引入新的实现而不影响用户
3. 低耦合
4. 能够减少变化带来的成本或影响

参考书目： UML和模式应用