说到设计模式，更为人所知的当然是GoF（Gang of Four）的23种设计模式。与GoF的23种设计模式不同的是，GRASP设计模式描述的是在OO设计中为互相协作的类分配职责的原则或者建议，而GoF的设计模式则是在更高的层次上描述一个OO系统或者其局部系统的行为以及结构上的抽象。
GRASP设计模式的全称是General Responsibility Assignment Software Patterns，即通用职责分配软件模式。这9个设计模式分别是：
- 创建者（Creator）
- 信息专家（Information Expert）
- 低耦合（Low Coupling）
- 控制器（Controller）
- 高内聚（High Cohesion）
- 多态性（Polymorphism）
- 纯虚构（Pure Fabrication)
- 间接性（Indirection）
- 受保护变化（Protected Variations）
就是一个类只干该干的事情，不该干的事情不干。在系统设计的时候，需要将每个类该做的事情也就是所说的职责分配给具有实现这个职责所需要的信息的类。
比如：
常见的网上商店里的购物车(ShopCar),需要让每种商品(SKU)只在购物车内出现一次，购买相同商品，只需要更新商品的数量即可。
针对这个问题需要权衡的是，比较商品是否相同的方法需要放到那里类里来实现呢？分析业务得知需要根据商品的编号(SKUID)来唯一区分商品，而商品编号是唯一存在于商品类里的，所以根据信息专家模式，应该把比较商品是否相同的方法放在商品类里。
在系统中引入抽象类或接口来提高系统的扩展性也可以认为是纯虚构模式的一种应用。
当我们的一个绘图程序需要支持不同的系统，那么因为不同系统的API结构不同，绘图功能也需要不同的实现方式，那么该如何设计更合适呢？如下图：
这里我们可以看到，因为增加了纯虚构类AbstractShape，不论是哪个系统都可以通过AbstractShape类来绘制图形，我们即没有降低原来的内聚性，也没有增加过多的耦合，可谓鱼肉和熊掌兼得！
“间接”顾名思义，就是这个事不能直接来办，需要绕个弯才行。绕个弯的好处就是，本来直接会连接在一起的对象彼此隔离开了，一个变动不会影响另一个。就像我在前面的低耦合模式里说的一样，“两个不同模块的内部类之间不能直接连接”，但是我们可以通过中间类来间接连接两个不同的模块，这样对于这两个模块来说，他们之间仍然是没有耦合/依赖关系的。
预先找出不稳定的变化点，使用统一的接口封装起来，如果未来发生变化的时候，可以通过接口扩展新的功能，而不需要去修改原来旧的实现。也可以把这个模式理解为 OCP（开闭原则），就是说一个软件实体应当对拓展开发，对修改关闭。在设计一个模块的时候，要保证这个模块可以在不需要被修改的前提下可以得到拓展。这样做的好处就是通过拓展给系统提供了新的职责，以满足新的需求，同时又没有改变系统原来的功能。
模块应该同时对扩展、可适应性开放和对影响客户的更改封闭。
抽象不应该依赖于细节，细节应该依赖于抽象。
比如，在一个系统中，类A依赖于类B实现。那么，当类A需要改变对类B的依赖，转而依赖类C时，类A必须修改源代码才能实现。而如果类A依赖于一个接口X实现，而类B和类C都实现这个接口，那么之后无论是类B和类C之间的替换，抑或是让类A去依赖新的类D，都是非常易于实现的。DIP的本质也是降低了耦合，将一个类与细节的耦合降低到了与接口的耦合，而与一个稳定的接口之间耦合是良好的。