设计模式就该这么学：为什么要学设计模式？（开篇漫谈）
引子：想象一下一个厨师，不学菜名如何跟人快速的交流。回锅肉，鱼香肉丝，龙井虾仁，狮子头，叫花鸡。请你换一种方式来介绍试试看。
设计模式也是，作为程序员之间的共同语言有必要学习下，别人讲个模式，而你并不懂，尴尬不，沟通成本也变高，当然更为重要的原因是，这是前辈们这么多年摸滚打爬总结总结出来有效经验总结，重要性自然不必多说，在我看来，学习设计模式的必要性就跟1+1=2一样明显。
笔者就遇到这样的情况，从事java开发工作也快两年了，有时跟同行交流下，直接聊死，因为对于这一块用到不多，知道有23种模式，但只用过几种，其他是一个模糊的概念，故觉得有必要系统的学习了解下，因为网上的文章良莠不齐，所以笔者选择了：【书+实际应用的经历】这种方式来进行学习（后面会介绍到笔者用到的书）。
这篇文章作为【设计模式就该这么学】系列的第一篇：是用来学习设计模式的预热，主要是谈一下为什么要学习设计模式！
后续，我会将每个设计模式单独成文，这些文章的的代码和文字将会基于实际的应用例子和书《Head First设计模式》根据自己的理解整理成文写出来，若有偏差，欢迎指正！
《设计模式就该这么学》系列文章:
一、什么是设计模式？
比起百度百科的解释，我更喜欢《研磨设计模式》一书中的定义，如下：
在软件开发领域，经过验证的，用于解决在特定环境下，重复出现的特定问题的解决方案！
注意上面提到的限定词，现在按我的理解来解释下。
1、软件开发
其实我觉得各行各业都有模式可以套用，这里的设计模式指的是在软件开发领域。
2、经过验证的
必须是经过大家公开验证的解决方案才算得上是设计模式，而不是说每个人随便工作解决的问题方案都算
3、特定环境
个人理解为就是不要脱离特定环境去使用设计模式，拿命令模式来说吧，我们开发中，请求-响应模式的功能非常常见，一般来说，我们会把对请求的响应操作封装到一个方法中，这个封装的方法 可以称之为命令，但不是命令模式。到底要不要把这种设计上升到模式的高度就要另行考虑了，因为，如果使用命令模式，就要引入调用者、接收者两个角色，原本放在一处的逻辑分散到了三个类中，设计时，必须考虑这样的代价是否值得，所以有必要考虑下环境。
4、重复出现
因为只有重复出现的问题才有必要形成固定方案，下次使用直接套用就是。
5、特定问题
不要觉得只会一种模式就可以走遍天下，那还要其他的模式做什么卵用，毕竟每种模式是针对特定问题的解决方案。
每个设计模式的构成如下：
1、模式名称：模式的一个好记的名字
2、环境和问题：描述在什么环境下，出现什么特定的问题
3、解决方案：描述如何解决问题
4、效果：描述应用模式后的效果，以及可能带来的问题
二、为什么需要学习设计模式
1、避免重复造轮子
前言也提到这是前辈们这么多年摸滚打爬总结总结出来有效经验总结，在特定环境下使用肯定事半功倍。比如我之前用观察者模式就很好地解决了实时解析某个指定目录下文件入库操作，后面会介绍
2、沟通更高效
农民b：那我大致了解你是怎么做的了
中农c：c，我觉得你这段代码可以应用XXX设计模式的
农民d：以我的理解在这种这个模块下，不适合用这种模式
3、易维护
因为遵循一个约定（即设计模式）写了一套代码，那么知道这一套约定的人就很容易理解的你的代码，维护自然更容易。
4、心法或意识形成
为什么一个相似的功能，大牛一会儿就搞定，然后悠闲地品着下午茶逛淘宝；而自己加班加点搞到晚十点还做不完。
为什么大牛写完的程序测试上线后，几乎完美运行，用户无懈可击；而自己的程序bug重重，改好一个却又引出另一个，按下葫芦浮起瓢，几近崩溃。
这不仅仅是因为大牛们工作比你久，是因为人家脑袋里就有这样的意识，在遇到特定的问题，人家很自然就能冒出这样的想法，同样的功能人家就是写出的代码就死可以比你的更容易维护，
系统也就更稳定。而你为什么不能，因为你根本就不知道有设计模式可用。
学习本就是一个不断模仿、练习、再到最后面自己原创的过程。
虽然可能从来不能写出超越网上通类型同主题博文，但为什么还是要写？
于自己而言，博文主要是自己总结。假设自己有观众，毕竟讲是最好的学（见下图）。于读者而言，笔者能在这个过程get到知识点，那就是双赢了。
当然由于笔者能力有限，或许文中存在描述不正确，欢迎指正、补充！
感谢您的阅读。如果本文对您有用，那么请点赞鼓励。
