设计模式很重要，但是很多人还是习惯性忽略，原因很简单：
  • 在面试中时常被问到设计模式，可实际工作中却很少使用；
  • 每个模式的样例代码都很熟悉，实际编码时却总感觉力不从心，实现困难；
  • 很多系统设计看上去和很多模式都很像，却不知道到底该用一个模式，还是多个模式；
  • 设计模式除了在编码阶段有用外，在设计上似乎用处并不大。
因为没有搞清楚它的应用范围和背景，才导致大多数时候我们总是在“生搬硬套”设计模式，以为在应用设计模式，实际上做了很多无用功。
因此，要想学好设计模式，就得摘去这些误解。「趣学设计模式」这个专栏，就首先帮你破除错误认识，树立正确的学习观念，之后的学习就事半功倍了。

误解一：经典模式太抽象，很难学下去

说到设计模式，你的第一反应是不是会想起“四人帮”GoF 的那本“经典”著作《设计模式：可复用面向对象软件的基础》？或者想起那 23 个“经典”的模式？
他们的确过于抽象，难以快速理解。而对于业余时间本就不多的你来说，更是难上加难的事。比如说，下面是《设计模式》一书中关于访问者模式使用场景的描述：
一个对象结构包含很多类对象，它们有不同的接口，而你想对这些对象实施一些依赖于其具体类的操作。
需要对一个对象结构中的对象进行很多不同的并且不相关的操作，而你想避免让这些操作“污染”这些对象的类。Visitor 使得你可以将相关的操作集中起来定义在一个类中。当该对象结构被很多应用共享时，用 Visitor 模式让每个应用仅包含需要用到的操作。
定义对象结构的类很少改变，但经常需要在此结构上定义新的操作。改变对象结构类需要重定义对所有访问者的接口，这可能需要很大的代价。如果对象结构类经常改变，那么可能还是在这些类中定义这些操作较好。
你会发现，即便很认真地阅读完，也看得似懂非懂， 这一段描述太长了，并且还掺杂了一些别的概念，查阅资料又得花费几分钟甚至几小时。
其次，表述太抽象。其中关于操作“污染”、不相关操作、不同的接口、改变对象的结构等，不同的人可能定义完全不同，就会导致在不同的真实场景中应用时千差万别。
最为关键的是，当你面对真实的业务需求时，如何才能快速选择最合适的设计模式？这个问题依然没有被解答。

误解二：设计模式太单一，复杂业务场景难落地

在理论学习中，几乎所有的开发人员都认为它很重要。大厂技术面试都会考查设计模式的相关知识点，优秀开源框架中都会用到设计模式。
在工作实践中，绝大部分开发人员在项目中又找不到合适的应用场景。比如，如何设计一个安全权限控制系统？如何设计容灾方案？从实际场景来看，设计模式似乎只能解决技术层面上的问题，业务上完全派不上用场。
其实，发生这个冲突的关键点在于：没有搞清楚设计模式解决问题的范围所在。换句话说，设计模式并不是一种全场景的解决方案，它需要考虑适用范围。否则问题是得不到有效解决的。

误解三：模式既然很好用，那么一切皆模式

设计模式原本是从不同的编程项目中总结出来的通用经验，是现存的既定事实，能解决很多工具、组件、框架复用的问题。
于是，很多人就认为编程时应该处处使用模式，并且用得模式越多，设计就越好。事实上，好的设计从来不是看用的模式有多少，而是看如何合理利用模式的设计思想，以及如何利用模式解决真实的问题。

如何正确学习设计模式

如何避免陷入以上 3 点误区，让经典真正为我所用呢？有以下四个很简单的方法。

首先，要摆正心态。

设计模式不是万能灵药，不是银弹，设计模式能解决的问题其实是有限的，你应该始终保持一个平常的心态，正确分析设计模式可以解决和不能解决的问题。不要总想着不思考直接使用。

其次，搞清楚设计模式的背景知识。

比如，设计模式如何定义？设计模式的历史演进与变化？设计模式有哪些适用的领域？又有哪些不适用的领域？如何结合实践分析和使用？你会发现，原来的知识会逐渐连接和串联起来，这是一个事半功倍的动作。

再次，努力具备高手独立思考的习惯。

资料和学习方法，会有很多前辈给你总结出来，你只需要花时间去主动学习+刻意练习，在失败和挫折中探索真实的能力长什么样，并借此不断强化你的能力。

最后，从现在开始，坚持。

大多数人的天赋都是一样的，最后成功的人只是多了坚持，希望你开始学习之后，一定不要中途放弃，一定要坚持住。
（1 元秒杀最后一天，今晚即将涨价）
就像你不能立即解决生活中的所有问题一样，设计模式同样不能解决这个世界上的所用问题，但是，只要你对设计模式进行不断地钻研与思考，设计模式就能带给你源源不断的新灵感和新希望。
继续阅读
阅读原文