对设计模式、重构的一点点小理解【完善版】
? 一、先说点偏题的，学习与动手实践的区别
?
?
二、我的理解
工作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：自己觉得代码局部范围有问题，耦合度强，职责不清晰，很难复用等，
原因：很可能是代码结构不好，没抽象好，没职责分配的不好，
解决办法：进行代码重构
?
?
在实际工作中，
为了进度，为了敏捷，
还有就是软件的本质：需求不确定，变化性，还有人的思维的局限性：很难面面俱到，
所以大部分，工作中是【设计模式+代码的重构】的增量迭代。
即，一开始简单出发，从确定的功能+能预期到的变化，进行简单设计， 然后完成功能，完成代码，融合再重构，改设计。。。
