1.1 什么是设计模式?

设计模式 其实早已是技术界烂大街的名词了,哪怕不是这个行业的人,也很可能问你一句:“设计模式到底是啥啊?听起来神叨叨的,你们不是敲代码的吗?怎么跟搞装修的似的?”。

 

当然这只是一个笑话,然而现实中,对于很多新手或者对面向对象不够深入的技术人员来说,设计模式是一个暧昧的存在,对设计模式有一种欲拒还迎的心态,认为它是一种比较难以掌握的技能,每每都是带着抵触的心态去接触和学习。又或者选用了极为晦涩的经典书籍去学习,被各种专业名词轰炸得五雷轰顶,头昏眼花,学习过程如同嚼蜡,最后草草放弃。当然还有最后一种情况,平时工作的时候,用的都是非常成熟的开发框架,大部分开发人员只需要遵从框架要求的开发规范即可,大部分高级点儿的编程技能压根就用不上,久而久之,别说设计模式(这里说的设计模式不是指 GOF 23,GOF 23 只是入门的东西),面向对象的三大特征估计都快忘了,如果不是为了面试下一份工作,估计都懒得看一看设计模式每个模式都叫啥,每个模式的应用场景又是什么?

 

设计模式其实并不复杂,设计模式说白了就是解决问题的方式方法。吃饭用筷子,晚上看书用台灯,冬天睡觉盖被子都是生活中非常典型的生活模式。设计模式就是这样一个简单的概念,生活中遇到问题后,我们的祖辈们根据问题出现的场景,为了解决问题找出了应对之策,并且得到一致的认可和推广,这就称之为解决这类问题的处理模式。到了面向对象编程,我们的前辈大牛们,把之前遇到的问题及其解决方案进行归纳总结,把编程思想中最精华的部分提炼出来,形成了编码界的设计模式,其中最知名的就是 GoF 四人帮 23 种设计模式。并不是这四个家伙技术层面上太牛B,而是这四个人更为有心。经过他们的整理和理论化之后,一举成名,他们成为了后来各种大会的高频嘉宾,在技术界至今都是网红一样的存在。他们的工作对于推动面向对象编程技术的布道起了非常用药的作用,所以简单致敬一下也是应该的。

 

在这里呢,我只想告诉大家,不要把设计模式想得太复杂,太有距离感。相反,它离我们太近了,就在我们的身边,因为它就是为解决我们工作中遇到的问题而存在的。工作的时候,我们搜肠刮肚的寻找解决某些问题的方案,殊不知,你看或不看,她就在那里,头顶红盖头等你。你学或不学,她就在那里,等待你发现她的好。虽说有 23 种,但是一半以上的设计模式,都非常的简单,而且有的模式,你看过之后甚至会嗤之以鼻:“这玩意儿也好意思归纳成一个模式,早不知被我用了多少年了”,就像现实社会中一样,我们会遇到简单的问题和困难的问题,之所以称之为简单的问题,主要还是因为我们可以通过简单的方式来解决。编程也是一样,对于简单问题的解决方案,大部分人的思路基本上也是一致的,所以才会形成共性的解决方案,大家理解起来也非常容易,学习设计模式的时候,有几个模式大家一看就能看明白。

问题说到现在呢,我们已经很容易理解模式了,但是为什么要加上 “设计” 这两个字呢,为什么不直接叫 “编程模式” 呢? 要回答这个问题,咱们还得回到面向对象。我们使用面向对象思想进行工作的时候,尤其是进行复杂业务逻辑产品开发的时候,要经过以下几个大的阶段: 

 

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

 

这是一个项目的基本流程,当然其中某些过程可能在实际的工作中会发生重叠和循环迭代,但这不是我们要讨论的重点,我们重点看 系统分析 系统设计,对应于我们面向对象语言,我们有 OOA(Object Oriented Analysis) 和 OOD (Object Oriented Design),说到这里我想大家应该明白设计二字是从何而来了。是的,设计模式是编程思想,是别人的先验之经验,设计模式主要就是在 OOD 面向对象系统设计这个阶段使用的,不要简单的认为这个阶段就要大规模敲代码了,对于复杂的系统来说,这部分消耗的时间和精力要高于程序开发阶段的,这个阶段出了问题,后边参与的人再牛X也只是徒劳,他们绝对会端着 AK47 去搞定进行系统设计的人。很多人对此不理解,尤其新手以及没有接触过大型项目的人。在大型项目当中,初级技术工作者们都是被放在被设计好的位置上开发或者维护已经设计好的模块或者小的功能点上,基本不可能看到整个项目是如何从 0 开始逐步成形的,最悲剧是工作多年后,依旧没有接触到更高一级的东西,人会越来越没有信心。

 

如果工作经历让一个人没有足够的积累和筹码支撑起自信的话,心态真的会崩的。07 年我在深圳经历过富士康令人恐惧的员工 13 连跳自杀事件之后,我知道了人如果对于未来看不到希望之后会有多脆弱。趁年轻,多学点东西总是好的,哪怕现阶段甚至未来两三年也用不上也不能成为不学习的理由。当我们只能看到 CRUD 的时候,我们也只能学会 CRUD,也只能成为CRUDer。

 

软件工程之所以能够成为一门不断发展的大学问,绝不只是一帮人在玩理论,是因为软件开发中除了技术问题,还加入世界上最为复杂的人类问题和社会问题,软件工程就是在从另一个角度或者维度探寻人类问题的设计模式,这话说得太形而上学了,反正就这么个意思吧。《人月神话》之所以长胜不衰,是因为其中所讨论的问题至今没有找到解决方法,不是解决不了技术问题,而是解决不了人的问题。

 

说着说着就跑偏了,但是希望你已经知道什么是设计模式了,我写作风格如此飘忽不定,也是难为大家了,之后会注意。我们不光要知道什么是设计模式,还要知道它在项目中的哪一个阶段应用。我们一定要培养项目思维,而不简单的停留在代码这个维度,代码只是重点解决了 程序开发 阶段的问题,整个项目其实是一个严格推导的过程,一个项目中,应该定义哪些类,定义哪些接口,设计哪些模块,如何分层,都是推导出来的。那种啥也别说,干就完了的工作方式,不是在解决问题,而是在生产 Bug 。

 

最后说一句特别特别俗套的话:“不要用一个锤子去解决你遇到的所有问题”。

 

评论区
乐乐 2018.09.11 11:26

很高兴看到博主又活跃起来了,没想到新开了个板块儿,写得真好,我们公司要是有你这样的高手给我们培训就好了,第一次发现设计模式还可以这么讲。

国营 2018.09.11 14:33

因为录视频不方便,所以加了图书这个板块儿,培训是个多被动的词啊,陪着训练,你看你多积极主动

Hello 2018.09.11 14:24

一看就知道博主也是个有经历的人啊

国营 2018.09.11 14:25

经历大家都有,能不能转化成丰富的经验就要看是不是有心了~

Hello 2018.09.11 14:28

博主一张嘴就出金句啊,肯定内功深厚,不然不会上来就写设计模式相关的东西,写的挺好的。GRASP 我之前没听过,但听过 SOLID 原则

国营 2018.09.11 14:38

我下一个系列就是 SOLID,居然被你提前剧透了。其实 SOLID 原则表述要清楚明了的多,GRASP 描述的太多晦涩,我当年第一次看见都觉得真不是给人写的,直接就扔一边了,跟看《易经》似的

dreamcc 2018.12.25 13:09

设计模式,我们公司老大,比我技术还水,还天天叼人,说真的,那天我就说了几个模式,说的他哑口无言之后,给我来了一句 鸟用,当然 鸟用这个词也被我美化了的事实上他对设计模式的嗤之以鼻,可以说完全不会的不懂的那种

国营 2018.12.25 14:30

如果你能技术这条路上一直走下去,将来有一天,你会忘了所有的套路,你也会忘了这些徒耗精力的模式和僵化的方法,只会剩下几个大的原则。到时候,你会说出跟你老大一样的话,甚至更难听:“TMD 卵用”。“设计模式”真的不值得吹捧,“设计模式”把很多人都带偏了,也被过度包装和神话了。我呢,用我文章中的话作为对结论:“并不是这四个家伙技术层面上太牛B,而是这四个人更为有心”,事实上,这几个家伙在纯技术上在当时甚至算不上入流,面向对象理解和使用到一定程度,是个人都会用这些套路,只是大部分人都在工作,没有去专门总结和命名这些东西,所以说他们推广面向对象上的贡献远高于“设计模式”本身的价值。他们的“网红”之路非常成功,比现在的网红都成功。一些老大级技术人员嘴里,你基本听不到市面上流行的“专业词汇”了,他们真的不需要这些东西,他们脑袋里更不会装这些扰乱心智的东西,不要让“设计模式”成为你前进道路上的鬼打墙。

2018.12.25 15:13

你的这段回复虽然不是写给我的,但是像搬砖拍在脑袋上一样,自己平时嘴里老挂着高大上的专业词汇,仔细想想的话,只是在装B罢了,或许只是在用这种方式掩盖自己技术不怎么样的心虚吧。

kobe 2018.12.27 02:14

我们公司老大欢迎你来我们公司带带我们这些技术,他觉得我们公司技术负责人太嫩太年轻,自己工作行,只能成全自己,却带不了人,成全不了团队。

kobe 2018.12.27 02:15

我也被你这段话一下子点醒了,过去真的某些方面挺盲目的,还是你看的明白

dreamcc 2019.01.07 16:13

技术赞 ·····技术栈····好吧 说实话 你的技术目前也属于我要仰望的那种

fhefh 2019.02.28 03:55

楼主写得很棒~ 学习了~

国营 2019.02.28 04:02

觉得网上很多文章都只是在拷贝粘贴,都没说到点子上,我不想自己写的东西也只停留在表面,所以就写了点大家没有注意过的东西

微信扫码登录