终于要开始正式开始 GRASP 了，古有庖丁解牛，今有 Codinget 强拆 GRASP，本篇文章只做一个简单的肢解，更复杂的内科手术会在后续章节中一台一台的做。

General — GRASP 的原则是通用的、广泛适用

GRASP 所说的良好的职责分配原则是放之四海而皆准的，并不狭隘的限于软件行业内，这也是为什么上一节文章中我说有些公司的项目还没有开始就注定要失败，因为如果公司内部本身就是权责不明，事理不清，宫闱恶斗。这样的公司要实现公司业务数字化，信息化，基本就是在浪费时间和金钱，除非先把自己内部的问题解决请了才行。

Responsibility — 责任，职责，义务

其实严格来说，只采用单词原意 “责任” 或 “职责” 是不够的，“权责” 似乎更为妥当。程序中的实体或者功能模块应当具备那种职责，负责什么，都需要分析清楚。现实社会中，不管在家庭还是公司或者某个组织内，我们的职责就是 “维护世界和平”，听着挺扯蛋是吧，但是仔细想象的话，不管是国家，政党，机构，家庭，人，我们做的所有事情无论大小不都是保障世界在现有格局和规则下平稳运行吗？所以虽然扯点蛋，但扯得力度并不大。

Assignment — 责任分配，职责安排

职责如何用更为合适的方式分配给指定的类或者模块是 GRASP 最核心的部分，分配职责的时候有很多的策略和方案。我们今天要简单介绍的 9 大要素，其实就是从9 个方面的大原则。根据这 9 个大原则，我们就可以将职责和负责这个职责的类（模块|系统）更好的组织在一起，为以后的程序设计阶段打下坚实的基础。

Software — 软件

这个就不用说了， GRASP 就是专门服务于软件行业的一种技术手段，所以就直接 PASS 了，不浪费咱们宝贵时间精力。

Patterns — 模式

这个也不拆了，这是一场美丽的误会，也是作者 辣馒 心中的一根刺，因为 Pattern 是作者当时的一个不恰当的用词，只是没想到 GRASP 流行的那么快，要是那个时候改成 Principles 多好，生米煮成熟饭后，想改也改不了了。 

之前第一章咱们也介绍了设计模式和 GRASP 的关系，可以说 GRASP 就是衡量一个设计模式是否是一个好的解决方案的标准。不然的话，咱们凭什么说 GoF 四人帮的 23 种模式就是普遍适用的好的解决之道呢？当然 GRASP 还可以用来衡量软件分层是否合理，因为分层就是在分工，分工就是在搞 “职责分配”，逻辑处理应该放在哪层？信息显示该放在哪一层？为什么现阶段大部分软件项目采用的三层架构设计（数据访问层，业务逻辑层，界面层）？这些问题的答案，咱们都可以从 GRASP 倡导的原则中找到其中的部分答案，在这里，我绝对不会说在这里能够找到所有答案，GRASP 虽然很好，但是也没有好到让我编瞎话去跪舔吹嘘的程度。如果没有统一的原则作为指导，一个公司的架构设计人员也会刀光剑影中争论不休。  

GRASP 对于面向对象的系统分析和系统设计具有重大的指导意义，有了它咱们就能把 “什么人该担什么职该做什么事” 这个老大难的问题解决好。面向对象的设计过程就是将责任分配给对象的过程。这章先说到这，把 9 个要素罗列一下作为结束吧，这九个要素中的某些要素，作者辣馒表述的相当晦涩，所以我会用更为生动的方式进行阐述。

• 信息专家 Information Expert
• 创造者 Creator
• 低耦合 Low Coupling
• 高内聚 High Cohesion
• 控制器 Controller
• 多态 Polymorphism
• 纯虚构 Pure Fabrication
• 间接 Indirection
• 预防变化 Protected Variations 

里面有熟脸，也有生面孔，除了英语单词让部分技术人员害怕以外，都是帝国主义不堪一烧的纸老虎，不为别的，就因为我们都是共产主义接班人。OK，本节结束。