这是我参与新手入门的第2篇文章
我相信很多人学习设计模式的经历是这样的：
-
在学校老师跟你说，不仅要学习框架，设计模式也非常重要。你开始了解学习设计模式，阅读经典的《Head First 设计模式》，这时候你会感叹设计模式的奇妙。
-
开始找工作了，你知道面试可能会问到设计模式相关的问题，你又再次投入精力学习设计模式，但这次你是抱着速成的心态在学习。
-
工作中，遇到复杂的业务场景，按照自己的想法写业务代码，你发现代码并没有那么优雅，扩展性不强，耦合严重，每次业务扩展，你都需要小心翼翼维护旧代码。这时候，你又想起设计模式，你从网上找来设计模式相关的博客，试图引入相关设计模式到项目中。
经过多次的学习，你是否已经学会了设计模式？我想答案是否定的。你能自然的说出设计原则吗？你能说出大部分设计模式吗？你能在项目不同业务场景中采用适当的设计模式吗？你能在面试中对设计模式领域的问题对答如流吗？
我们为什么要学习设计模式？
有些人可能觉得，大牛不用刻意学习设计模式，很自然的就把它运用到编码中了。对~这没错！可是，我们大部分人都不是大牛，我们需要刻意学习，以达到事半功倍的效果。
大牛们可能在一两个项目实践中就领悟到很多设计模式的思想精髓，而普通人可能在三、五年，甚至更长时间，才慢慢领悟设计模式（有可能始终都是模糊的状态）。而我们通过刻意学习，可以更有效率的掌握设计模式。自然领悟就像「无师自通」，刻意学习就像跟着有经验的师傅学习。毕竟「名师出高徒」的概率远大于「无师自通」的概率。
写出更好的代码
编码时，我常常会想，什么是「好」的代码。
从微观角度，我们可以很容易的说出几条：命名规范，词能达意；运行效率高；节省内存；采用合理的数据结构和算法等。
宏观层面（系统层面）来说，好的代码是高聚合低耦合、扩展性强的。我们怎么才能写出这样的代码呢？遵循基本的设计原则（如单一职责原则），采用合适的设计模式。设计模式就是前人总结下来的经验，是各种业务场景下的经典解决方案。
提升开发效率
在实际项目中，迭代是非常频繁的。新的功能不断迭代，有时会发现新的功能跟系统已有功能很像，你想着这个好办啊，直接复用原来的代码就可以了。但实际动起手来，才觉得事情不简单啊：旧代码并不支持直接复用，需要对原代码稍作改动。改好之后，新功能可以正常使用了。你以为大功告成了，突然测试同学跑过来跟你说，原来的功能出问题啦！你才意识到新的改动影响了旧的逻辑！好吧~我旧代码不动！copy一份代码出来改造。
如果你使用了设计模式，系统具有很好的扩展性，每次迭代，不需要耗费大量精力考虑对旧业务的影响。这样就可以大大提升开发效率
面试需要
这可能是最不值得一提的一点，面试并不是学习的目的。但对我们来说，它可能是最重要的。
如何学好设计模式
回到最初的问题: 为什么学了很多次设计模式，还是没学会。有以下三个原因：
- 在学校的学习，没有学以致用。
- 应付面试的学习，没有深入学习。
- 遇到问题的针对性学习，没有系统学习。
深入学习——追问事物的本质
如果只是粗浅的学习设计模式，那只会在脑海留下一个「印象」，随着时间的推移，逐渐淡忘。追问事物的本质，就是大脑思考的过程。比如，学习某个设计模式，你思考这个模式的概念是什么，为什么它重要，如何理解它，使用它有什么意义，如何正确的使用它，它跟其他同类的设计模式有什么区别。
阅读源码，也是追问事物本质的一种方式。
系统学习——建立知识体系
我们常说的融会贯通，就是各方面的知识或道理融合贯穿起来，从而得到系统透彻的理解。建立知识体系，就是把各个知识点连接起来，形成一个知识网。系统全面的学习设计模式，就是建立设计模式的知识体系。当遇到实际问题时，你就可以通过某个知识点及其千丝万缕关系的找到问题的答案。
学以致用——应用所学知识
所学的设计模式，如果不实际应用到项目中，那一切都是纸上谈兵。真正掌握设计模式就是能运用相应的设计模式解决实际问题。而实际应用设计模式，反过来又加深了对设计模式的理解。
The end
接下来我将持续更新设计模式系列文章，以「深入学习」、「系统学习」、「学以致用」为方向，与大家共同学习设计模式！
