通用职责分配模式的其中的３模式
通用职责分配模式(GRASP)一共有９个模式，下面是其中的３个模式：
创建者模式：
创建对象是面向对象系统中最常见的活动之一，因此应该有一些通用的原则以用于创建职责的分配，如果分配的好，设计就能够支持低耦合，提高清晰度，封装性和可复用性。
如果下列条件之一为真，将创建类A的实例的职责分配给类B：
a.B包含或组成聚集A
b.B记录A
c.B直接使用A
d.B具有A的初始化数据，并且在创建A时会将这些数据传递A。因此对于A的创建而言，B是专家。
e.B是对象A的创建者
如果有一个以上的选项适用，通常首选聚集或包含A的类B。
创建者模式指导我们分配那些与创建对象有关的职责。基本意图是寻找在任何情况下都与被创建对象具有连接的创建者。创建者模式建议，封装的容器或记录是创建其所容纳或记录的事物的很好的候选者。
对象的创建者常常具有相当的复杂性，例如为了性能而使用回收的实例，基于某些外部特性值有条件的创建一个或一族类的实例。在这些情况下，最好的办法是把创建职责委派给称为具体工厂或抽象工厂的辅助类，而不是使用创建者模式所建议的类。
信息专家模式
信息专家经常用于职责分配，这是对象设计中不断使用的基本原则。专家并不意味着模糊或奇特的想法，它表达一种直觉，即对象完成与其所具有的信息相关的职责。
注意，完成职责往往需要分布在不同对象中的信息。这意味着许多局部的信息专家要通过协作来完成任务。
信息专家模式是对真实世界的模拟。我们一般把职责分配给那些具有完成任务所必需的信息的个体。
在某些情况下，专家模式建议的方案也许并不合适，通常这是由于耦合与内聚问题所产生的。
我们可以用设计要分离主要的系统关注来改善设计中的耦合和内聚。该模式通常支持高内聚。
低耦合模式
耦合是对某元素与其他元素之间的连接、感知和依赖程度的度量。具有低耦合的元素不会过度依赖于其他元素；“过度”是与语境相关的，但我们必须对此进行检查。这些元素包括类、子系统、系统等。
具有高耦合的类依赖于许多其他的类，这样的类或许不是我们所需要的，有些类会遇到以下问题：
a.由于相关类的变化而导致本体的被迫变化
b.难以单独理解
c.由于使用高耦合类时需要它所依赖的类，因此很难重用。
低耦合是在制定设计决策期间必须牢记的原则，它是应该不断的考虑的基本目标。
在C++ JAVA 和C#这样的面向对象语言中，从TypeX到TypeY耦合的常见形式包括：
a.TypeX具有引用TypeY的实例或TypeY自身的属性
b.TypeX对象条用TypeY的对象服务。
c.TypeX具有以任何形式引用TypeY的实例或TypeYT自身的方法。通常包括类型TypeY的参数或局部对象，或者由消息返回的对象是TypeY的实例。
d.TypeX是TypeY的直接或间接子类
e.TypeY是接口，而TypeX是此接口的实现。
低耦合提倡职责分配要避免产生具有负面影响的高耦合。
低耦合支持在设计时降低类的依赖性，这样可以减少变化所带来的影响。低耦合不能脱离专家和高内聚等其他模式孤立的考虑，而应作为影响职责分配的原则之一。
子类与其超类之间有很强的耦合性。因为这是一种强耦合形式，所以要考虑涉及超类导出的任何决定。
没有绝对的度量标准来衡量耦合程度的高低，重要的是能够估测当前耦合的程度，并估计增加耦合是否导致问题，一般说来那些有着自然继承关系的类和复用程度较高的类，具有较低的耦合性。
低耦合的极端例子是类之间没有耦合。这个例子违反了对象技术的核心隐喻：系统由相互连接的对象构成。对象之间通过消息通信。耦合过低会产生不良的设计，其中会使用一些缺乏内聚性、膨胀、复杂的主动对象来完成所有工作，并且存在大量被动、零耦合的对象来充当简单的数据知识库。对象之间的适度耦合，对于创建面向对象系统来说是正常和必要的，其中的任务是通过被连接的对象之间的协作来完成的。
