GRASP

General responsibility assignment software patterns 通用职责分配模式。

分配原则

Creator :

Information Expert:

Controller:

   

高级原则

Polymorphism:

Pure Fabrication:

Indirection:

Protected Variations:

   

衡量原则

Low Coupling:

High Cohesion:

   

Creator

2008年12月4日

13:29

谁负责创建某类的新对象？

   

如果以下成立，把创建类A实例的职责分配给类B。

• B"包含"或组成聚集A。
• B记录A。
• B直接使用A。
• B具有A的初始化数据，并且在创建Ａ时，会将这些数据传递给Ａ。
• B是对象A的创建者。

   

Information Expert

2008年12月4日

13:29

   

信息专家。

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

A：把职责分配给信息专家，他具有实现这个职责所必须的信息。

H：分配职责应当从清晰地描述职责开始。

   

Do It Myself策略：软件对象所做的操作，通常是作用于它们在真实世界中所代表的非生命体的那些操作。

对象的有生命原则：就好象来到了卡通世界，所有的软件对象，都是活得，善于hip-hop，并且承担着自己的职责，完成任务。

   

信息专家是对真实世界的模拟，把职责分配给具有完成任务所需信息的对象。

   

但是要注意，不要违反基本架构原则：设计要分离主要的系统关注。

例如不要把对象的业务逻辑与持久化放在一起，这样将导致非常高耦合。

   

Low Coupling

2008年12月4日

13:29

   

Q：如何降低依赖，减少变化带来的影响，提高复用性。

W：耦合？

1.由于相关类变化，导致自己变化。

2.难以独立完成任务。

3.依赖类过多。

A：分配职责，使耦合性尽可能低，这个是重要的评估原则。

   

   

注意，对象技术的核心隐喻：系统由相互链接的对象构成，对象之间通过消息通信。

   

Controller

2008年12月4日

13:29

   

Q :UI层之上，谁是首先接受系统操作，的对象。

A：控制器是第一个对象，负责接受和处理系统操作。

H：控制器是外观控制器的变体，但是为了降低耦合，可以有多个这样的置于ui层的用例控制器。--Pure Fabrication

这些控制器，和ui层没有任何关系，而是代表业务上的 系统，根对象，执行场景，用例控制器。

I：控制器通常要把工作委派给其他对象，控制器只是协调这些活动。

   

   

High Cohesion

2008年12月4日

13:29

   

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

A：在分配职责时保持较高的内聚性。

   

Polymorphism

2008年12月4日

13:29

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

w：如果使用了switch,if等判断逻辑，扩展性将会很差。

A：当相关行为随类型有所不同时，使用多态操作，作为变化的行为类型分配职责。

H：不要测试对象的类型，也不要使用条件逻辑来执行基于类型的不同选择。

   

   

Pure Fabrication

2008年12月4日

13:29

   

Q：当你不想违背high cohesion and low coupling 时，并且也不想违背 info expert..你穷途末路。。。

A：创造一个纯粹虚构的类，并且是高内聚，低耦合的。

H：如，数据访问层。

w：

类对象的设计可以被广泛地分为两组。

1.通过表示解析所产生的选择：这种软件类涉及或代表领域中的事物。支持 低表示差异。如tableOfContent

2.通过行为解析所产生的选择：通过行为分组或通过算法来分配职责。如 tableOfContentCreator.

   

纯虚构通常是通过行为解析。

   

I：如果对象内的大部分数据被传递给其他对象处理，那么很可能出现了问题，如过多的纯虚构对象。

所有的设计模式！都是纯虚构。

   

Indirection

2008年12月4日

13:29

   

Q：为了避免两个或多个事物之间直接耦合，应该如何分配职责？如何使对象解耦合？

A：将职责分配给中介对象，使其作为其他构件或服务之间的媒介。中介实现了其他构件之间的间接性。

H：

计算机科学中的大多数问题都可以通过增加一层间接性来解决。

计算机科学中的大多数性能问题都可以通过去除一层间接层来解决。

w：

   

Protected Variations

2008年12月4日

13:29

   

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

A：识别预计变化或不稳定之处，分配职责用以在这些变化之外创建稳定接口。

H：封装变化。

w：

注意不要让消息链过长。

   

不要和陌生人讲话 的约束，在方法里只应该给以下对象发送消息。

1.this对象

2.this的属性。

3.this的集合属性中对象。

4.方法的参数。

5.方法中创建的对象。

   

预测 PV 和选择你的战斗。

变化点--现有的系统或需求中的变化。

进化点--将来的变化点。

转载于:https://www.cnblogs.com/zhuispeed/archive/2009/10/17/1584997.html