如果没记错的话《Head First 设计模式》这本书买的已经是第三遍了，真可谓是收藏一直在路上，学习从未能开始，真正的开始学习之前我觉得有必要复盘下之前两次失败开始的原因。
- 第一次买这本书是读研二下学期的时候，那个时候听说这本书很好，刚好实验室经费可以买书，于是就买了这本书，但是结果是草草翻了几页了事，现在应该还躺在实验室的某个角落，至于原因主要是当时在积极的准备面试所以各个方面的知识也就是都做到简单知道两个即可用来应付面试而已，说白了就是设计模式这个角度的面试题随便找两篇八股背背了事，没有时间学习
- 第二次买这本书应该是2020年在当时的公司有段时间工作不太忙，想看看有什么好学习的，就找到了设计模式。但是因为当时公司使用的语言是C#，而这本书主要语言是Java，所以就以此为借口把书搁置一旁了。实际上还是没有恒心。
以上两次失败开始的主要原因大抵可以总结如下：
- 表面原因：语言不一致，C#和Java有些不通；着急准备面试没功夫细细探究
- 核心原因：没有养成长期学习的习惯，恒心差，随时会被别的事情打破学习节奏
- 底层原因：对于技术的体验和了解还没有到阶段，依旧沉迷于具体的术而未开始踏足抽象的道，很多大佬说要学原理，不过也需要从浅层再到原理，所以之前在浅层阶段的术也是必经之路
那么现在为什么又要捡起来了呢？
- 语言终于回到Java了，生态也是Java的生态，工作中有时是会遇到一些设计上的难题，无从下手。很多东西都是凭感觉去设计，没有理论依据，但感觉会给人一种不可靠的反馈，会心虚，担心自己的设计之后不好扩展，代码越来越臃肿成为屎山。
- 过去两年从2020年初开始到现在养成了一个长期的学习习惯，不管工作忙还是不忙，都已经将学习作为一种习惯来接受了，所以是会从生活中预留充足的时间去学习的。
- 过去两年接触了比较广泛的知识，从中间件（kafka、redis、elasticsearch）到数据库的底层原理、各类java框架（spring、springmvc、springboot）、远程调用框架（retrofit、dubbo）等等，感觉对术的积累已经到了一定阶段，并且在学习各类知识底层原理的时候偶尔能抽象出一些共性的东西，隐约能体会到一些诸如：高内聚、低耦合、面向接口编程、retrofit代理调用、mybatis动态代理、kafka订阅-通知、spring全局单例、工厂方法等等，但是这些思想都是支离破碎的，没有统一的描述
所以第三个原因：底层原因看起来有点悬乎，实则是最终驱使我投入这块学习内容的关键，当一个知识成为你对技术掌握的痛点后，学习完才最有效果，收获才最大，同时大量的实践也将给我指明具体的学习路径。于是我将设计模式加入到今年一个重点学习计划：
并且有别于年初的优先级2，把它提到一个高优的位置去学习，接下来的三个月左右估计都是在于设计模式共舞了。行文至此，分享下《Head First 设计模式》关于设计模式的学习阶段：
- 初学者的心智： 初学者到处使用模式。这很好：初学者可以借此培养许多使用模式的实战经验。初学者也认为“我使用越多模式，我的设计就越好”。初学者将慢慢认识到并非如此，所有的设计都应该尽量保持简单。只有在需要实践扩展的地方，才值得使用复杂性和模式
- 中级人员的心智：随着学习的进程，中级人员的心智开始能够分辨何时需要模式，而何时不需要。中级人员的心智依然会企图把过多的模式套用在不适当的地方，但他们也开始察觉到有些模式并不适合目前的情况，可以对其改编以使其适合。
- 悟道者的心智：悟道者的心智能够看到模式在何处能够自然融人。悟道者的心智并不急切于使用模式，而是致力于最能解决问题的简单方案。悟道者的心智会考虑对象的原则，以及它们之间的折衷。当对模式的需要自然出现时，悟道者的心智就拿捏得宣地采用模式。悟道者的心智也能看到相似模式之间的关系，以及它们在意图上的微妙差异。悟道者的心智也同于初学者的心智不会让这此模式的知识过度影响设计的决策。
初学者拿着业务找模式，中级者在业务需要的时候使用模式，悟道者可以随心所欲不逾矩的使用模式，此时模式也不再具体，而是实现业务的方法而已，可以理解为模式内化为经验，成为下意识的选择了吧。
