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

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

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