GRASP 是 General Responsibility Assignment Software Patterns 的缩写，翻译过来咋翻译呢？江湖上比较流行的翻法是《通用职责分配软件模式》，我呢，比较懒，没有刻意强调“软件”二字，直接叫他《职责分配模式》，GRASP 的提出者是个洋人（Craig Larman）。辣馒 绝对是个不打折扣的了不得的家伙，在编程界以及软件工程领域那可是个响当当汉子，很多人都是在他的影响下走上正途的，有兴趣的话可以人肉一下他，我就不过多介绍了。

还是回来继续说咱们的，虽然最后一个单词是 Patterns，但是等你把 GRASP 所有的东西学完之后，你会发觉 “模式” 这个说法不怎么恰当，与其说是模式，不是说是一些 原则和指南。GoF 四人帮的才是严格意义上的模式，而且是系统设计阶段采用 OOD 方式的设计模式。再来看一看职责分配这四个字，这四个字才是 GRASP 的灵魂所在，我们现在需要把 “职责分配” 在项目的执行阶段中做一个基本的定位： 

项目立项 - 获取需求 - 需求分析 - 系统分析 - 系统设计 - 程序开发 - 测试 - 项目交付 

职责分配发生在哪个阶段呢，需求分析 、系统分析、系统设计 这三个阶段。在 获取需求 这个阶段，我们会得到系统中的 干系人 ，干系人这个专业词语最早出现在项目管理学中，不要畏惧新名词儿，都是纸老虎而已。生活中有了矛盾，我们总说某个人在某件事上逃不了干系，干系人的“干系”跟这里的干系其实是一个意思。干系人就是使用我们软件产品的所有人，比如用户，系统的管理员，运营人员，老板等等。除了干系人，我们还会在这个阶段得到 干系事 （也可能是在需求分析阶段分析出来的），当然这是我恶搞干系人发明的新词儿，意思就是软件中的功能。不管是人还是功能或者说业务，它们都需要进行 “职责分配” ，而职责分配不是小孩儿过家家，是有大学问在的。不同的人有不同的权限和责任，不同的业务有不同的规则和资源分配方案，哪怕是相同的业务因为干系人的角色不同也会变化规则，话说起来弯弯绕，其实道理很简单，普通玩家和人民币玩家永远都不是一个物种。在现实社会中 “人”、“事”、“职”、“责” 是怎么回事，到了软件系统中，也是那么回事，我们不过就是把现实社会的规则通过代码进行了逻辑化。 只有分析清楚了 “人”、“事”，“职”、“责” 之后，才能谈到 职责分配。

我们对它做好了 基本定位 之后，我们就会明白，为什么它对于我们学习和理解设计模式这么重要，为什么它倡导的原则比设计模式本身还要重要，只有职责清楚，并且能够分配清楚，才能进行 系统设计 和 程序开发。在业内大家都听过一个说法，失败的项目占所有项目的比例其实是非常高的，很多软件项目其实还没有做的时候就注定会失败，因为 “职责分配” 是超出软件范畴的，如果一家公司想把它们的业务信息化，那这家公司内部本身的 “人”，“事”，“职”，“责” 等等必须都是清楚明白，且执行到位的才行，如果它自己内部本身就是一团浆糊，人浮于事，人与人之间，部门与部门之前，职位与职位之间界限不明，责任不清，遇事推责揽功，宫斗不断，就不要指望这类公司的项目能做成，必定是失败的项目。而很多无良的软件公司通常喜欢这样的项目，因为项目失败的 “责” 不在自己身上，只要配合这类公司的项目负责人“演戏”，任由他们修改需求，把项目周期无限制的拖下去即可。

这里面有一件极为讽刺的点就是：技术人员即便在这种混乱的项目中也能把 “职责分配” 做好，因为技术层面上，会排除具体人的因素，而是以 角色，业务，权限 等等逻辑方式去解决问题，摒弃了绝大部分人情世故，鸡鸣狗盗，世态炎凉的社会化规则，因此这类项目也能完成和交付。至于交付之后，他们用不用，能不能坚持用，就是另外一回事儿了，哪怕交付了，这也不能算是成功的项目。

说到逻辑层面呢，GRASP 模式着重考虑的就是 “类” 的 设计原则 及其 职责分配，而 GoF 设计模式则主要考虑 OOD 阶段设计如何实现，类与类之间如何交互，程序结构如何更加健壮，易扩展，易维护。GRASP 是 GoF 设计模式的前提，GoF 设计模式就是符合 GRASP 模式原则要求的面向对象的设计模式。GRASP 是武林秘籍的总纲，是路线规划方案，GoF 就是根据规划制定好的具体可实施的路线了。这是它们之前最根本的区别。国内有相当一部分技术书中，总是全方位比较它们的不同，连不能对比的东西也要比一下，驴唇不对马嘴的罗列出来一张表格，我认为这种方式过于吹毛求疵了，真的是被中国的应试教育给毁了，一定要让学习的人按照写书人的方式去思考和解决问题。最重要的东西反而不着重说明，为了显得专业（也可能是凑字数）刻意比较那些没有意义的东西，反而把人的注意力带偏了。

 Ok，本章内容就是这些了，我们也要准备正式进入 GRASP 和设计模式的世界了，我想这可能也是大家第一次看到有人这么写设计模式了，因为我想把设计模式还原到项目的情景当中去说明，不想采用市面上设计模式书籍那种只讲模式而不言它的讲解模式，设计模式也是有亲戚朋友的和社会关系的，只单看设计模式，是很难真正理解它的。