《重构-改善既有代码的设计》笔记

读完《重构——改善既有代码的设计》，感觉写得真是非常得好，非常的细腻而且深入，建议还没有读过的找时间读一读，肯定受益良多。

之前写程序也总是不停的重构、重构，读完这本书之后才发现对于重构的理解以前是很肤浅的，很不成体系的。《重构》真是一本好书！
下面粗略地概括一下对重构的理解，也整理一下之前不是很清楚的概念。

１、《重构》有一个很好的动机，也可以说是价值观，就是程序第一是写给人看的，而不是写给机器看的。
根据这一价值观，其他多种利益纷至沓来，比如当程序有了良好的可读性和可理解性，程序中隐藏的Bug便很容易浮出水面，开发进度也更加顺畅，并且对于系统将来的结构变更和扩展，程序也更加具有灵活性。

２、《重构》与《设计模式》的关系，在《设计模式》和《重构》中都有提出“设计模式为重构提供了目标”，在之前对这句话的理解总是朦朦胧胧，觉得有道理但又不是很深刻，现在觉得有两个词非常的关键：目标和目的。

设计模式为重构提供了目标，但不是目的。

设计模式是经过证实的在一定场景下解决一般设计问题的解决方案的核心，通过设计模式我们很好得解决了某种问题，并且便于我们思考和交流，降低沟通之间的理解误差，此外同样重要的，设计模式增强了可复用性，便于将来扩展和维护。

而重构是对程序内部结构的一种调整，其目的是在不改变“软件之可察行为”的前提下，提高其可理解性，降低其修改成本（《重构》的名词性定义）。

所以如果我们把软件开发比作在大海中航行，设计模式就是遍布在大海中的航标，他可以引导我们驶向目的地——高可读性、可理解性、可扩展性、可维护性。所以设计模式是重构的目标（航标）而不是目的，设计模式可以帮助我们更好更快的抵达目的地（准确地说是无止境的），而避免触礁或偏离航向

３、重构和优化，在之前的开发中，优化的意识要比现在（看完《重构》之后）强的多，如果遇到在一个循环中可以做多个事情的时候，决定把每件事情分开放到单独的循环中是要鼓起很大的勇气的，而现在便可以轻松的决定，因为清晰的代码在需要性能优化时有更宽的道路可以选择，并且往往这种决定不会造成真正的性能影响。

此外代码的坏味道Bad smells一章，真是一顿营养丰富的大餐。Duplicated Code是代码腐化的万恶之源，Long Method、Large Class、Long Parameter List这些几乎就是旧社会臭婆娘的裹脚布，Divergent Change、Shotgun Surgery、Feature Envy、Inappropriate Intimacy这些简直就是指责不清勾肩搭背。等等。。。

重构，它为我们清除这些坏味道指明了方向，并且《重构》通过强调“重构是一种有纪律的、经过训练的、有条不紊的程序整理方法”，保证了重构过程的安全性和高效性。

在重构的手法中有相当一大部分是双向的、互逆的，也就是说在某种时候是你找我，而在另一些时候是我找你，比如Pull Up Field和Push Down Field，Pull Up Method和Push Down Method等，而另一些则是强调单向的、勇往直前的，比如Encapsulate Field、Remove Control Flag、Remove Parameter、Remove Assignments to Parameters、Replace Conditional with Polymorphism等。
在双向的、护逆的重构手法中，强调的是一种平衡，是职责清晰，角色明确。
而在强调单向的、勇往直前的重构手法中，突出的是使代码更容易理解、更容易扩展，更加具有面向对象性。

为了对比双向可逆的重构手法，以便突出其侧重点和权衡内容，下面进行列举
重新组织你的函数章节中
Extract Method——Inline Method
Inline Temp——Introduce Explaining Variable

在对象之间搬移特性章节中
Extract Class——Inline Class
Hide Delegate——Remove Middle Man
Introduce Foreign Method——Introduce Local Extension

重新组织数据章节中
Change Value to Reference——Change Reference to Value
Change Unidirectional Association to Bidirectional——Change Bidirectional Association to Unidirectional

简化条件表达式章节中
无

简化函数调用章节中
Add Parameter——Remove Parameter
Parameterize Method——Replace Parameter with Explicit Methods

处理概括关系章节中
Pull Up Field——Push Down Field
Pull Up Method——Push Down Method
Extract Subclass（Extract Superclass）——Collapse Hierarchy
Replace Inheritance with Delegation——Replace Delegation with Inheritance

在看这本书的过程中感觉这种互逆的挺多，列举之后发现没有之前感觉多。

我觉得设计原则(OCP等)，设计模式，重构是软件设计的三个重要组成部分。
大家怎么看？

我也这么觉得，设计原则，设计模式和重构三者相互联系，互为补充，共同组成软件设计的整体过程

设计原则是软件设计的指南，借以可以指导设计出优秀的软件（具有清晰、可扩展、可维护等等特性）；

设计模式是设计原则在某种场景下的事例体现，是已证实的符合设计原则的某种解决方案的核心，可以重复拿来使用；

而重构则是在后期对现有代码的整理，通过进一步组织函数、数据、类结构和等等，使代码更加清晰设计更加优秀；

Bad smells一章 可以当作程序员的自我修养来读

说句实在话，设计原则，设计模式，重构的终极思想，就是要忘掉这些模式，譬如张无忌学太极剑，忘光了就是学会了。死啃书本，不在项目中领会这些知识，等于没学，甚至等于邯郸学步。

自从看了重构这本书后，逐渐的在项目开发当中应用，确实改善了程序的阅读性，结构性，优化性等，感觉很有用，虽然有些东西还没有理解的特别深刻

呵呵，我觉得终极思想不是忘掉这些模式，而是通过实践的磨炼，经验的积累，达到对设计理念的心领神会，对设计决策的信手拈来，以无招应有招，而这里的无是心领神会，随心所欲的无，而不是忘光的无

这其中最大的差别是忘光的无，是可以在一知半解的时候就可以忘光的，而随心所欲的无，是需要对招数达到一定熟练程度，对更好层次的理念达到融会贯通之后才能做到的

而且我觉得现在有一种现象，当然这种现象只是从我身边来看，可能不完全具有代表性，就是现在的开发人员不像几年前那样对于设计具有那样大的热情，起码热情的普遍性很差。

那些大佬们，象Robbin，cookoo，buaawhl以及老庄等等可以现在不谈论设计，不谈论模式，但是这不是说他们以前没谈论（反而是谈论的太多了，谈的没感觉了，即到了无的境界了），更不能说明现在不需要谈论

可能这有几方面的原因：
1）敏捷方法的突起，一方面要求简化设计，另一方面重构可以帮我们容易的改变设计；
2）框架（Struts,webwork,spring,hibernate）的日益丰富，使的在一般需求下，只按照框架规定的模式就可以顺利进行开发

楼上说得很有道理