衷心感谢改版期间大家给予的帮助和体谅

微信登录

微信登录

因恶意注册过多,目前只支持微信模式

1.3 GRASP 模式与 GoF 设计模式有啥不一样?

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 和设计模式的世界了,我想这可能也是大家第一次看到有人这么写设计模式了,因为我想把设计模式还原到项目的情景当中去说明,不想采用市面上设计模式书籍那种只讲模式而不言它的讲解模式,设计模式也是有亲戚朋友的和社会关系的,只单看设计模式,是很难真正理解它的。我的这种写作方式难度比较大,但是我会尽最大努力去完成,水平有限,望纰漏处各位高人们不吝赐教~

 

 

 

cohaha 2018.09.11 07:30

博主,我越来越觉得你藏得太深了,这么晦涩的 GRASP 你也能讲的这么接地气,我过去看 GRASP 压根看不进去

codinget 2018.09.12 10:57

我最早也看不进去,作者辣馒的风格其实挺学究气的,理解起来挺费劲的,有时候语言就是这么有魅力,哪怕原本明白的东西,经他们这些抽象派大师一“翻译”,哇塞,我怎么好像又不懂了呢~

西门撸码 2018.11.06 11:15

现在很少有人这么用心写东西了,大都喜欢东拼西凑了

lyri.lpc 2018.12.25 05:47

博主,“人与人之间,部门与部分之前”,这里没检查。写得真好,继续拜读!

codinget 2018.12.25 05:53

感谢,比我心细多了

lyri.lpc 2018.12.25 06:16

没有没有,因为很喜欢你写的东西,而且自己有点菜,理解的慢,只能慢读。

找一条适合自己的路,坚持走下去
编程原力 京ICP备17045322号-2
版权所有, 侵权者追究法律责任