<1>Craig Larman在《Applying UML and Patterns》一书中提出了GRASP设计模式的概念。
<2>作者称其为设计模式，其实，更好的理解应该为设计原则。
<3>GoF设计模式是针对特定问题而提出的解决方法。
<4>GRASP则是站在面向对象设计的角度，告诉我们怎么样设计问题空间中的类与它们的行为责任，以及明确类之间的相互关系等等。
<5>GRASP可以说是GoF等设计模式的基础。
<6>GRASP：
General Responsibility Assignment Software patterns
通用职责分配软件模式
<7>核心思想：
“职责分配（Responsibility Assignment）”
用职责设计对象："Designing Objects with Responsibilities“
<8>进一步理解核心思想：
自己干自己的事（职责的分配）
自己干自己的能干的事（职责的分配）
自己只干自己的事（职责的内聚）
五个基本模式
1、信息专家（Information expert）
2、创建者（Creator）
3、高内聚（High Cohesion）
4、低耦合（Low coupling）
5、控制器（Controller）
四个扩展模式
6、多态性（Polymorphism）
7、纯虚构（Pure Fabrication）
8、间接性（Indirection）
9、防止变异（Protected Variations）
GRASP模式中解决类的职责分配问题的最基本的模式。
问题
当我们为系统发现完对象和职责之后，职责的分配原则（职责将分配给哪个对象执行）是什么？
解决方案
1、职责的执行需要某些信息（information），把职责分配给该信息的拥有者。换句话说，某项职责的执行需要某些资源，只有拥有这些资源的对象才有资格执行职责。 --“有能者为之”
2、满足了面向对象设计的封装性的设计，一般情况下都会满足Information Expert模式。因为Information Expert是对类的属性（信息），以及对类的属性的操作的封装，它符合对象封装性的概念。
优点
1、信息的拥有者类同时就是信息的操作者类，可以减少不必要的类之间的关联。
2、各类的职责单一明确，容易理解。
GRASP模式中解决类的实例的创建职责问题的模式。
问题
类的实例的创建职责，应该分配给什么样的类？或者说类的实例应该由谁创建？
解决方案
以下条件之一为真的情况，类A的实例的创建职责就分配给类B。
1、B包含A
2、B聚集A
3、B记录A
4、B频繁使用A
5、B有A初始化数据
提倡类的实例（对象）创建职责由聚集或包含该对象的对象创建
优点
1、整个结构清晰易懂
2、有利于类或组件的重用
3、防止职责的分散
4、降低耦合性
GRASP模式中为降低类的复杂程度，简化控制而提出的面向对象设计的原则性模式。高内聚（High Cohesion）与低耦合（Low Coupling）模式是GRASP其他模式的根本。
问题
怎么做才能降低类的复杂程度，简化控制？
解决方案
紧密相关的功能（职责）应该分配给同一个类。–“各司其职”
所谓内聚，是指单个物体（类）内部的功能聚集度。比如，只包含有相互关联的功能的类，具有高内聚性，同时，它的外部表现（作用，意图）也就明显；反之，如果一个类由一些不相关的功能构成，它的内聚性就低，它的外部表现就不明显，一方面很难理解它的作用和意图，另一方面，一旦需求变化，扩展性就差。
优点
1、聚集相关功能，结构清晰，容易理解
2、只聚集相关功能，使得类的职责单一明确，从而降低类的复杂程度，使用简单
GRASP模式中为降低类的复杂程度，简化控制而提出的面向对象设计的原则性模式。高内聚（High Cohesion）与低耦合（Low Coupling）模式是GRASP其他模式的根本。
问题
怎么做才能降低类之间关联程度，能适应需求的变化呢？
解决方案
为类分配职责时，应该尽量降低类之间的关联关系（耦合性）。亦即，应该以降低类之间的耦合关系作为职责分配的原则。
所谓耦合，是指多个物体（类）之间的物理或者意思上的关联程度。在面向对象方法中，类是最基本的元素，耦合主要指不同类之间相互关联的紧密程度。面向对象里的关联，主要指一个类对另一个类的调用，聚合（包含），参数传递等关系。比如，所谓2个关联得非常紧密的类（高耦合），是指其中一个类发生变化（修改）时，另一个类也不得不跟着发生变化（修改）。
面向对象设计要求类之间满足“低耦合”原则，它是衡量一个设计是否优良的的一个重要标准，因为“低耦合”有助于使得系统中某一部分的变化对其它部分的影响降到最低程度。
优点
1、一方面，高内聚要求把紧密关联的功能（职责）聚集在同一个类中，防止功能的扩散和类的无谓增加，从而减少类之间的关联，降低类之间的发生耦合的机率。
2、另一方面，高内聚要求把不相关的功能分散到不同的类，类增加了，势必造成相互关联类的增加，从而增大类之间发生耦合的机率。
GRASP模式中解决事件处理职责问题的模式。
问题
在UI层之外，应该由哪个类来处理（控制）系统操作（事件）呢？或者说，当触发一个系统事件时，应该把对事件的处理职责分配给UI层之外的哪个类呢？
解决方案
把系统事件的处理职责分配给Controller（控制器）类。
Controller模式提倡用一个专门的类来处理所有的系统事件。或者说Controller模式把所有系统事件的处理职责分配给一个专门的类集中处理。
优点
1、防止同类职责的分散。满足高内聚，低耦合原则。
2、有利于共通处理（前处理，后处理等）。
3、变化的高适应能力。能够把变化的修改范围控制在最小范围（控制器）之内。
问题
如何处理基于类型的选择？如何创建可插拔的软件构件？
解决方案
当相关选择或行为随类型（类）有所不同时，使用多态操作为变化的行为类型分配职责。
问题
当你并不想违背高内聚和低耦合或其它目标，但是基于专家模式所提供的方案又不合适时，哪些对象应该承担这一职责？（很多情况下，只对领域对象分配职责会导致不良内聚或耦合，或者降低复用潜力）
解决方案
对人为制造的类分配一组高内聚的职责，该类并不代表问题领域的概念——虚构的事物，用以支持高内聚，低耦合和复用。
所有GOF设计模式（或其它模式）都是纯虚构。
问题
为了避免两个或多个事物之间的直接耦合，应该如何分配职责？如何使对象解耦合，以支持低耦合并提供复用性潜力？
解决方案
将职责分配给中介对象，避免它们之间的直接耦合。中介实现了间接性。
大量GOF模式，如适配器、外观等等都是间接性的体现。
问题
如何设计对象、子系统和系统，使其内部的变化或不稳定性不会对其它元素产生不良影响？
解决方案
识别预计变化或不稳定之处，分配职责用以在这些变化之外创建稳定接口。
几乎所有的软件或架构设计技巧，都是防止变异的特例，比如封装、多态、接口、虚拟机、配置文件等。
1、数据驱动设计（Data－Driven Design）：通过外置、读取并判断变化因素，防止数据、元数据或说明性变量等对系统产生影响。
2、服务查询（Service Lookup）：Data－Driven Design的特例，如JNDI，UDDI，通过使用查询服务的稳定接口，客户能够避免服务位置变化的影响。
3、解释器驱动的设计（Interpreter－Driven Design）：系统通过外置、读取、解释逻辑而避免了逻辑变化的影响。
4、反射或元级的设计（Reflective or Meta－Level Design）可避免逻辑或外部代码变化的影响
5、统一访问（Uniform Access）：如C＃中的XXX.Name
6、标准语言（Standard Language）
7、Liskov替换原则（LSP）：在对T有任何替换实现或子类（成为S）情况下，引用类型T（某接口或抽象超类）的软件（方法，类……）应该正常或按照预期工作。
8、得墨忒耳定律（Law of Demeter）：不要经历远距离的对象结构路径去向远距离的间接对象发送消息。
9、开放－封闭原则（OCP）：模块应该同时（对扩展、可适应性）开放和（对影响客户的更改）封闭。
GRASP和GoF都是称为软件开发模式，只是描述的内容和角度不同。
GRASP和GoF是不同类型的模式，出发点不同。GRASP是解决类之间如何交互，如何设计合理，和具体问题无关。
GoF往往是解决一些具体的问题，比如类的具体创建方式等等，而GRASP是解决对象分析的一些基本原则，即你如何去设计你的问题空间中的类和它们的行为，是原则性的东西。
GRASP适用于对象分析和设计中，即在RUP的制作分析模型和设计模型阶段，GoF更适用于在实际编码过程中作为更加具体的指导思想。