重构
出版社:中国电力出版社
出版日期:2003-8-1
ISBN:9787508315546
作者:Martin Fowler
页数:464页
作者简介
Martin Fowler和《重构:改善既有代码的设计》(中文版)另几位作者清楚揭示了重构过程，他们为面向对象软件开发所做的贡献，难以衡量。《重构:改善既有代码的设计》(中文版)解释重构的原理（principles）和最佳实践方式（best practices），并指出何时何地你应该开始挖掘你的代码以求改善。《重构:改善既有代码的设计》(中文版)的核心是一份完整的重构名录（catalog of refactoring），其中每一项都介绍一种经过实证的代码变换手法（code transformation）的动机和技术。某些项目如Extract Method和Move Field看起来可能很浅显，但不要掉以轻心，因为理解这类技术正是有条不紊地进行重构的关键。点击进入该书更多详细信息。
发布书评
精彩书评 (总计52条)
-
Martin Fowler 的《重构-改善既有代码的设计》这本书，是我大学老师推荐给我的。 当时我在撰写代码过程中，发现当代码量到某个数量级时候（1000+行）， 就会逐渐失去对代码的控制能力。昆哥推荐了两本书《UML和模式应用》和《重构》这本书。这本书是2年前购买的，可惜以我当时的代码感知和撰写能力，看起来颇为吃力。 半途就看得云里雾里而中断了。最近我又重新拾起这本书， 将书中所写的境况与我这两年多来遇到的问题相互印证，才感受到这本经典的力量。Martin 其人：ThoughtWorks的首席科学家，当今世界软件开发领域最具影响力的五位大师之一。他在UML推广普及、领域建模、企业应用开发和敏捷方法等方面建树卓著，被称为软件开发的教父。大学时候有段时间我对 Martin 的敏捷非常痴迷。现在对技术的选择没以前那么冲动了， 但是毫不妨碍我对 Martin 的敬仰之情。1. 重构原则1.1. 重构的定义对软件内部结构的一种调整，目的是在不改变”软件之可察行为“前提下，提高其可理解性，降低其修改成本。重构就是在代码写好之后改进它的设计。重构和添加新功能并不冲突，但是当开发者身份在两者之间切换时候，不能混淆在一起。1.2. 重构的意义优秀设计的根本是：消除重复部分！（DRY = Don’t repeat yourself）重构让代码更清晰，更容易理解清晰的代码可以更方便的找到bug，重构可以写出更强健的代码良好的设计可以在长远时间上提高开发速度1.3. 重构的时间随时进行重构（在我看来，重构更是一种开发的习惯）事不过三，代码重复不要超过三次（否则就要”抽“出来）添加功能时候并一一重构（个人理解是，添加新功能之前，分析并重构，从而更方便添加新功能）修补错误时code review时1.4. 重构和开发进度重构的意义之一也是提高开发进度。杀手锏是”不要告诉经理“。1.5. 重构的难题数据层（数据模型）的变更压力修改接口那些难以通过重构改变的设计改动代码不能运行项目期限压力 dead line1.6. 重构与设计编程不是机械的开发，（软件开发是艺术行为！）设计和重构的平衡（预先设计的难度和重构灵活性的平衡）1.7. 重构与性能重构确实会在短期内降低代码执行效率，但优化阶段是可以调整的，而且调整会更容易。提前优化是万恶之源1.8. 那些Bad Smell重复的代码（这才是真正万恶之源，鄙视一切Ctrl+C/P）过长函数，会导致责任不明确/难以切割/难以理解等一系列问题过大类，职责不明确，垃圾滋生地过长参数列（面向对象不是说说而已）发散式变化，一个类会响应多种需求而被修改散弹式修改（其实就是没有封装变化处，由于一个需求，多处需要被修改）依赖情节（一个类对其他类过多的依赖）数据泥团（如果数据有意义，就将结构数据变成对象）type code，使用Class替代switch，少用，考虑多态过多平行的类，使用类继承并联起来冗余类，去除它夸夸其谈的未来性（Matin的文字，侯俊杰的翻译真是…出彩…）临时值域，封装它过度耦合的消息链，使用真正需要的函数和对象，而不要依赖于消息链过度的deleate过度使用其他类private值域重复作用的类不完美的类库，（类库老了，使用者也没办法阿）纯数据类（类需要行为）不纯粹的继承（拒绝父类的接口的类）过多注释，注释多了，就说明代码不清楚了1.9. 从测试开始无测试，无重构，只依赖手工测试，重构时候人会崩溃的。重构的保真就是自动化测试（如果真的要无聊的手工测试，我也不反对）单元测试功能测试1.10. Kent Back说如果我纯粹为今天工作，明天我将完全无法工作。间接层的价值：* 允许逻辑共享* 分开解释”意图“和”实现“* 将变化加以隔离* 将条件逻辑加以编码计算机科学是这样一门学科：它相信所有问题都可以通过一个间接层来解决。 --Dennis DeBruler我相信，撰写代码时候不仅仅考虑当下功能，要考虑到有可能出现的情况， 在可能的平衡下面，为将来的扩展做好准备。（也许不仅仅是自己的明天， 还要考虑团队成员的今天工作内容）2. 重构名录2.1. 重新组织函数Extract Method（提炼函数）将一段独立的，不依赖上下文的代码组织并独立出来。Inline Method（将函数内联化）当函数内部代码简短而容易理解时候，去除这个非必要的间接层。Inline Temp（将临时变量内联化）去除只被赋值一次的临时变量。（当有意义时候，应该保留）Replace Temp with Query（以查询取代临时变量）将临时变量提取到一个独立函数，并将原来变量引用替换为函数调用。 （我还是担心性能的问题，另外将临时变量限定在一个段落p中，可以避免额外的引用）Introduce Explainning Variable（引入解释性变量）将复杂表达式的结果放入临时变量，并用变量名来解释表达式用途。 （自注释代码的表现）Split Temporary Variable（剖析临时变量）除了循环变量和临时集合变量，临时变量赋值不能超过一次。Remove Assignments to Parameters（移除对参数的赋值动作）不对函数参数进行赋值动作，如果要赋值，创建一个新的临时变量。Replace Method with Method Object（以函数对象取代函数）把函数变成对象，再把临时变量变成对象值域。该方法在分解函数时候常用。 （Martin 对小型函数特别迷恋，我认为这个方法更应该用在有逻辑意义的方法上面）Substitute Algorithm（替换算法）用更清晰的算法。 （码农都知道）2.2. 在对象之间搬移特性（面向对象编程原则之一就是职责归属，搬移其实也就意味着职责重新规划）Move Method（搬移函数）将函数移动到被最多次调用的类里面去。 （往往在逻辑意义上，这个函数就应该归属于这个类）Move Field（搬移值域）将值域移动到被最多次调用的类里面去。Extract Class（提炼类）将开发过程中逐渐变得臃肿的类拆分成数个类，形成清楚的抽象，明确的职责。Inline Class（将类内联化）将不再担任足够职责的类搬到另外一个类中，并移除这个原始类。Hide Delegate（隐藏委托关系）将直接调用变成间接，在中间添加一层，从而从容面对变更，隔离变化。 （“哪里变化，封装哪里”这是设计模式的一个经典原则）Remove Middle Man（移除中间人）和Hide Delegate相反，移除做了过多简单委托的类。 （应该Hide Delegate需要加入成本，多维护一层，这需要控制一种平衡）Introduce Foreign Method（引入外加函数）当类无法进行修改时候，使用静态函数接受这种类型的类实例，Introduce Local Extenstion（引入本地扩展）使用子类继承/wrapper类来实现额外的函数。2.3. 重新组织数据Self Encapsulate Field（自封装值域）使用getter/setter。 （个人觉得这样很繁琐，.net中的属性方式处理的不错）Replace Date Value with Object （以对象取代数据值）当数据项有额外的数据和行为时候，将它变成一个类Change Value to Reference（将实值对象改为引用对象）有一些类型，比如日期、星期，不需要保存太多副本。Change Reference to Value（将引用对象改为实值对象）和楼上相反的情况，引用会带来复杂的内存分配，在分布式系统中，实值对象特别有用。Replace Array with Object（以对象取代数组）不应该将不同的元素存放到数组中，应该使用值域。Duplicate Observed Data（复制被监视数据）通过观察者模式，将业务数据和GUI数据进行同步控制Change Unidirectional Association to Bidirectional（将单向关联改为双向）使用双向连接，从而能让两个类能互相使用对方特性。Change Bidirectional Assicuation to Unidirectional（将双向关联改为单向）当一个类不再需要另外一个类特性时候作修改。Replace Magic Number with Symbolic Constant（以符号常量/字面常量取代魔法数）使用有意义的名称，比如pi,gravity。Encapsulate Field（封装值域）使用getter/setter。Encapsulate Collection（封装集群）避免直接修改容器对象，而是封装出类方法来修改。将变化控制在既有方法内。Replace Record with Data Class（以数据类取代记录）将传统编程中的结构体转换为数据类。Replace Type Code with Class（以类别取代型别码）使用类型集合类来替换型别码。Replace Type Code with Subclass（以子类取代型别码）使用多态来替换型别码，发挥面向对象编程的优势。 （小心处理ORM映射）Replace Type Code with State/Strategy（以State/Strategy取代型别码）使用State/Strategy模式来因对type code会发生变化的情况。 将状态类作为父类，再进行继承。Replace Subclass with Fields（以值域取代子类）当子类的差异仅仅体现在返回常量数据的函数上时候，进行这样的替换。2.4. 简化条件表达式简化的核心思想，是将过程式的if/else替换为面向对象的多态。Decompose Conditional（分解条件式）将复杂的条件式提炼为独立函数。Consolidate Conditional Expression（合并条件式）将多个条件式判断提炼成一个独立函数。这和上面的分解条件式都需要一个前提： 这几个条件式是要有逻辑关联的。Consolidate Duplicate Conditional Fragments（合并重复的条件判断）将所有分支里面都拥有的代码提炼到分支判断之后运行。Remove Control Flag（移除控制标志）使用 break/return 取代控制标记。单一出口，多出口。控制标记让程序接口看上去混乱。Replace Nested Conditional with Guard Clauses（以卫语句取代嵌套条件式）保留正常情况下面下的顺序执行，提前对非正常情况进行单独检查并返回。 （我更倾向于使用Exception）Replace Conditional with Polymorphism（以多态取代条件式）将条件式的每个分支放入一个subclass内覆写函数中，然后将原始函数生命为抽象函数。 （这个方法之前的5种重构手段是代码小手段，引入多态才能充分发挥OOP优势）Introduce Null Object（引入Null对象）将无效值替换为null object，从而可以让程序正常运行。 （这好象是一种hack方法，我倾向使用Exception，作者的用以可能是通过Null来减少判断代码）Introduce Assertion（引入断言）通过断言来发现程序错误，实际使用中，可以配合 debug mode 使用。2.5. 简化函数调用Rename Method（重命名函数）A good name is better than a line of comment.Add Parameter（添加参数）你没看错，就是添加参数。 （啊？Matin老师，不带这么水的阿）Remove Parameter（移除参数）不要就丢掉。Separate Query from Modifier（将查询参数和修改参数分离）将一个即查询状态又修改状态的函数分离开来，职责分离清楚。 （我以前很喜欢写多面手函数～）Parameterize Method（令函数携带参数）同一逻辑功能函数，通过重载接受不同参数。而不要建立多个同样的函数。Replace Parameter with Explicit Methods（以明确函数取代参数）将单一函数分解为多个函数从而去掉参数，前提是这几个函数的逻辑功能区别较大。Preserve Whole Object（保持对象完整）传递完整的对象，取代几个参数的传递。Replace Parameter with Methods（以函数取代参数）如果目标函数需要的是几个参数操作的结果，就直接传递这个结果，而不是数个参数。Introduce Parameter Object(引入参数对象)当几个参数经常同时出现，就封装他们。 （他们之间往往就有逻辑关系）Remove Setting Method（移除设值函数）如果类的某个值域初始化后不再改变，就去掉它的setting方法。 （我理解为原则：“减少疑惑，保持唯一”）Hide Method（隐藏某个函数）使用 private 标记未被其他类调用的方法。Replace Constructor with Factory Method（以工厂函数取代构造函数）引入工厂模式。Encapsulate Downcast（封装向下转型动作）当知道什么类型时候，将其封装在产生函数里面，减少引用者的困扰。Replace Error Code with Exception（以异常取代错误码）如其名。 （关于异常使用的时机，抛出的方式，捕捉的粒度，我困惑了很久。 最后的总结的经验是：在什么层级处理并且仅处理该层级的异常。等有时间详细成文送出）Replace Exception with Test（以测试取代异常）异常不是条件判断。2.6. 处理概括关系关于 OOP 继承的那些事儿。Pull Up Field（值域上移）子类重复的值域放到父类去。 （其实还是基于责任归属的问题）Pull Up Method（函数上移）子类中重复函数移到父类。Pull Up Construction Body（构造函数本体上移）共用的构造函数片段上移。Push Down Method（函数下移）将父类中近被某个子类调用的函数下移。Push Down Field（值域下移）同上。Extract Subclass（提炼子类）当某个类只有部分特性被用到，就需要提取出子类。Extract Superclass（提炼超类）和上面相反。Extract Interface（提炼接口）将相同的子集提取接口。Collapse hierarchy（折叠继承体系）父类和子类并无太大区别时候，合体吧亲。From Template Mehod（塑造模板函数）将子类的同功能不同实现函数上移到父类，并在子类提供同名不同实现被调用的子函数。Replace Inheritance with Delegation（以委托取代继承）将父类变成一个值域，在调用这个值域的方法。is-a → has-a （继承太多就会出问题）Replace Delegation with Inheritance（以继承取代委托）和上面相反的应用，当子类和父类出现明显的继承关系时候使用。2.7. 大型重构这一章讲的内容有点高屋建瓴，这里就不概括了，建议读原文。Tease Apart Inheritance（梳理并分解继承体系）Convert Procedural Design to Objects（将过程化设计转化为对象设计）Separate Domain from Presentation（将领域和表述/显示分离）Extract hierarchy（提炼继承体系）少年，coding时候重构你的代码吧！版权所有 © 2010 转载本站文章请注明： 转载自Log4D 原文链接: http://log4d.com/2012/02/refactory 您可以随意地转载本站的文章，但是必须在醒目位置注明来源及本站链接，不可以将本站文章商业化使用，或者修改、转换或者以本作品为基础进行创作。 3a1ff193cee606bd1e2ea554a16353ee -
我第一次看这本书的时候是对java了解不多，只是听别我说这本书好，于是看了一下，可是看不懂。现在又重新拿起了这本书，感觉里面还是有用，在实际中要多用 -
英文版 : 花了一个月的时间读完了这本书的英文版本。对英语不太有自信的朋友（譬如我），建议对照着中文版来看。因为有些单词翻译过来还是不明白意思，譬如， ‘nibble away’这个词，google翻译为‘蚕食远’，而中文版翻译为‘慢慢处理’。章节介绍：第一章展示的小程序一下子就拉近了读者和重构之间的距离，顿时有种重构走下神坛的感觉。第二章介绍理论知识，略带乏味。第三章的bad smells一点点的让我想起，当初自认为写的很健壮的代码，但现在看来很有问题的。5-12章的精彩自不用多说。尤其是第12章big refactorings，帮我瞬间拉回到四个最为普通的案例来。继承和委托应该使用哪一个，各自的优势是什么？如何将一个过程式的设计转变为面向对象式的？如何将表现和逻辑相分离？哇！！！看的太精彩太过瘾了！这些可都是程序员心中萦绕已久的问题啊！13，14，15章因为我资质较浅，没能参透... ...16章真的像作者说的一样，起到了画龙点睛的效果。尤其是作者提到的当你无法再继续重构下去的时候， 等下来歇息一下，想一想，等想好了再继续出发。还有就是书中几乎每一页都有提到的'step by step'简单精炼至极。合上这本书后，按耐不住激动之情，马上来这里写下这些文字，以纪念这一个月来陪伴我度过无聊生活的‘朋友’。我相信我不会从此冷漠它，接下来的编程生涯我会带着他一起走完。
精彩短评 (总计50条)
-
经典。重构时最有快感的事就是删除一大段一大段的代码，去年在工作中要重构一个1000行代码的方法，二三十个if/else判断，用的方法就是书中第九章提到的以多态取代条件式。 -
介绍了重构的定义、原因和方法。其实主要就是调整程序结构使其更清晰。 -
也许是平时就是这么干的，所以帮助不是很大，只是了解了些东西，看了一遍后，在也没激情看第二遍了。 -
挺好的。推荐。在coding中走了很多弯路，再看这种书，才会觉得每一句都极有道理。
能教给你的不只是重构的方法，也能改正不良代码习惯。 -
太艱深了沒看完 -
各种 Code Smell 以及详尽的重构手法列举，一本不可多得的手册 -
少一刻星是因为: 这里介绍的都是基本招式,可实际问题的都tm是精英怪,boss怪. -
My first English book. How to refactor all the bad codes -
搞开发的，必读的书啊，真是必须得读的。 -
大师是靠细致的方法积累起来的。 -
读这本书时犹如获得一本武林秘诀。 -
用来检查一下自己写的代码是否漂亮 -
对于很多编程上的风格问题，作者都给出了合理的解释。比如防御性编程，大家都知道有这么一种编程风格，但是作者把这样做的原因解释的非常清楚。 -
值得一看。 -
学习了 -
-
这本书真正帮助我明白了一件事,就是设计没有所谓最好,而是适用,
根据你的情况一步步的实现你的设计,
根据你的需求一步步去完善它,
代码大全让我了解设计的原则
这本书让我掌握一步步走的技巧
个人习惯把问题拆分拆分
结合测试驱动技术,
这本书可以很好的减少修改和大提交带来的bug率
典型的改善过程来提升代码效率的质量管理之道
当是读的是英文版
感觉简直是开了挂,
从此对英文版书不再恐惧,
而是喜欢 -
写 Java 的一定要看看这本书，对于以代码行数来计算 KPI 的员工尤其适合【误，其实真的是一本非常好的书，减少代码的重复性和耦合性 -
后面几章大致浏览了一下，以后需要时再细细研究~ -
人与自然处事上的不同风格：现实世界中物种重复基因越多，越容易适应环境。[于是这种“思维差别”可以用来解释“为什么寻求真理如此艰难”之类的问题吗？]
-
里面的很多重构方式在实际中已经使用，很多都不需要讲得这么细 -
第一本完完整整看完的技术书籍，以前看书都是看一部分跳过一部分 -
书的结构很清晰，最开始介绍了什么是重构为什么要重构以及什么时候需要重构等，之后通过很多简短的示例详细讲解了重构的经验方法。很容易读 -
书中不仅定义了各种代码的坏味道，也针对性的提出了相应的重构手段，使重构成为一门有章可循的技艺。当然，运用之妙存乎一心，具体如何使用还要看实际操作者的水平。和期待的有一些差距扣一分。 -
读了前面五章，收获颇多。
读完之后，觉得写代码的标准高了。怎样的代码才算代码？行为和数据都服务于本对象的，在对象里发生改变，在对象里结束改变。尽可能每次修改只让一个对象发生改变。 -
不适合初学者，进阶必读 -
很多方法在重新修改自己已有程序的时候都会遇到 -
工程实践中总结出的非常实用的技能和思想。 -
条理清楚，深入浅出，原理方法实践相结合，很容易看懂。 -
整个系统的稳定性在于不断的重构向前，目前项目中直接用到了诸多里面的方法，非常具有可操作性。本书加上Intellij的重构工具，极大的提高了编码效率 -
把各种常识和非常识都化为标准，繁复而精美。 -
论如何把给电脑看的代码重构成给正常人看的 -
大师之作，值得反复读 -
重构、可读代码艺术、代码整洁之道这三本，如果能理解深层含义，三选一即可。 -
有些地方翻译的很涩，有的没实例 -
影响我代码风格的书 -
并没有读完，里面很多重构的方法对于现在来说应该是常识。 -
绝对经典，指引我开发思想多年的经典之作 -
事无巨细 有些过时，很多设计已经融在框架中了 -
虽然现在大家都会重构,但是这本书系统性地分析与讲解非常值得细细评味 -
很受益的一本书～ -
简单易懂， 写得很好，对我影响很大 -
书整体挺好的，代码稍稍有点过时，不过Java 1.5之前真是无法直视 -
这本书绝对很屌，其实细细想来，无非是一些经验的大合集。影响代码质量的，除了程序员的设计能力之外，还有两个不可控的点，一个是毫无节制的需求变更（你不能说你的程序能适应任意方向的扩展吧？）另一个就是时间紧迫——尤其是这点，往往是导致代码质量差的根本原因——而这本书也解决不了这两点。 -
还是有必要看一下吧, 虽然很多地方不说有多少实用价值. -
重构要有点设计模式思想和对变化的理解 -
看完以后深深觉得，OO好麻烦。换句话说，混合编程或许更好。另外翻译扣一星。 -
重构就是修改软件，在保持软件行为的基础上改变软件结构。 -
对于我这种半路出家的码畜来说还是很有用的 -
接触编程也有几年的时间了，里面讲了不少的知识，很多都在自己在不知不觉中使用过，都是摸爬滚打出来的，要是早一点看这书可能成长的速度会更快