一、先说点偏题的，学习与动手实践的区别
二、我的理解
工作2 年多来，看了一些设计模式、重构的书籍、资料。
现在自己突然觉得：
设计模式和重构其实讲的是同一个东西，他们的思想和原则其实是一样或者说是相近的，只是从不同角度和方向而已。
设计模式、重构是从不同的出发点，用了一些相近的思想和原则来指导我们如何写出更合适的代码。
1 、设计模式更多的是从设计的角度出发，来指导的。是从上到下
过程 是【问题-- 分析、设计（key ）-- 最优答案】
2 、重构更多的是从代码角度，从优化角度，来指导的。是从下到上
过程 是【问题-- 一般答案-- 优化（key ）-- 最优答案】
设计模式强调 分析、设计，强调思考、思想
重构强调 先动手，有错就改
如果是解决同一个问题，
A 、不管你是用设计模式，从设计角度出发，一开始用设计模式中得原则和思想来分析，然后完成代码。
B 、还是你是先写代码，完成功能，然后用重构中得原则、思想、方法来对代码重构，然后得到这种代码。
如果都得到最优结果，不管你是用A 方式，还是用B 方式，我觉得代码结构是非常相近的。
所以我认为设计模式和重构其实是同一个东西。
三、我的心得体会
工作中：【尽量少用设计模式，一定要多重构】
（原因不好说，我也说不清楚。
我主要认为的是，设计模式会让开发进度漫长，很容易过度设计，可能会让代码变的复杂，易读性降低。
另外，
重构后的代码就会慢慢趋向模式，因为这两种手段的最终最优结果是一样的 ）
我的这些心得体会，一切一切的原因都是 ：
1、 无论是谁，对业务【现实世界】、系统【代码】的理解，都是逐步深入的，你不可能一下子就会对业务、和未来的系统有很深入的理解；
2、 现实与系统是有差距的，不同的，即现实世界的问题、逻辑与代码中逻辑、问题是有差距的，不同的；
3、 有一些代码中得东西、问题，并不是从现实世界中分析、抽象出来；
设计模式中有很多原则：单一职责、关闭、依赖倒置、迪米特等等，
重构中也有很多手段和方法，
但我觉得设计模式和重构的思想中，最重要的分两个类别（这两个类别有交差）：
抽象 、职责 、耦合度 、变化的和不变的
【 1 、抽象：类、函数的真正作用或者说其思想，不是封装，而是抽象。必须学会抽象，抽象出相同的部分，封装其变化的 部分；
2 、职责：这个太重要了，一定要认真分析每个类、每个模块、每个组件的职责，是设计模式和重构最关键的部分。在分析职责的时候，不仅仅只分析自身的职责，还要分析跟外部的联系，这也是其职责的一部分。
3 、耦合度：耦合度包括两部分-- 现实世界中耦合的抽象，降低代码维护成本、复杂度的需要使用的武器。
】
理想中得过程：
1 、接近完美的设计------ 》2 、接近完美的代码
现实中较好的过程：
1 、一个不错的抽象框架与设计----- 》2 、一个不错的代码架构----- 》3 、逐步重构代码----- 》4 、完善设计---- 》5 、接近完美的代码
真正工作中的过程：
1、 脑子里有的大部分是功能方面的逻辑和思路，只有非常少得抽象------ 》
2、 用面向对象的语言，开发面向过程的。【这一步有很大的作用，能很快很容易加深对业务和代码的理解】------- 》
3、 情况A ： 觉得整体代码、结构很烂、很臭、不舒服、不清晰等等，
原因：很可能设计上有问题，设计的不够好，
解决办法：这时候，需要用加深后的理解，重新设计或者完善设计。
情况B ： 自己觉得代码局部范围有问题，耦合度强，职责不清晰，很难复用等，
原因：很可能是代码结构不好，没抽象好，没职责分配的不好，
解决办法：进行代码重构
在实际工作中，
为了进度，为了敏捷，
还有就是软件的本质：需求不确定，变化性，还有人的思维的局限性：很难面面俱到，
所以大部分，工作中是【设计模式+ 代码的重构】的增量迭代。
即，一开始简单出发，从确定的功能 + 能预期到的变化，进行简单设计， 然后完成功能，完成代码，融合再重构，改设计。。。