重构

出版时间：20101028  出版社：人民邮电出版社  作者：Martin Fowler  页数：431  
Tag标签：无  

前言

"重构"这个概念来自Smalltalk圈子，没多久就进入了其他语言阵营之中。由于重构是框架开发中不可缺少的一部分，所以当框架开发人员讨论自己的工作时，这个术语就诞生了。当他们精练自己的类继承体系时，当他们叫喊自己可以拿掉多少多少行代码时，重构的概念慢慢浮出水面。框架设计者知道，这东西不可能一开始就完全正确，它将随着设计者的经验成长而进化；他们也知道，代码被阅读和被修改的次数远远多于它被编写的次数。保持代码易读、易修改的关键，就是重构——对框架而言如此，对一般软件也如此。好极了，还有什么问题吗？问题很显然：重构具有风险。它必须修改运作中的程序，这可能引入一些不易察觉的错误。如果重构方式不恰当，可能毁掉你数天甚至数星期的成果。如果重构时不做好准备，不遵守规则，风险就更大。你挖掘自己的代码，很快发现了一些值得修改的地方，于是你挖得更深。挖得愈深，找到的重构机会就越多，于是你的修改也愈多……最后你给自己挖了个大坑，却爬不出去了。为了避免自掘坟墓，重构必须系统化进行。我在《设计模式》书中和另外三位作者曾经提过：设计模式为重构提供了目标。然而"确定目标"只是问题的一部分而已，改造程序以达到目标，是另一个难题。

内容概要

　　《重构：改善既有代码的设计（英文版）》清晰揭示了重构的过程，解释了重构的原理和最佳实践方式，并给出了何时以及何地应该开始挖掘代码以求改善。书中给出了70多个可行的重构，每个重构都介绍了一种经过验证的代码变换手法的动机和技术。《重构：改善既有代码的设计（英文版）》提出的重构准则将帮助你一次一小步地修改你的代码，从而减少了开发过程中的风险。

作者简介

作者：（美国）福勒（Martin Fowler）Martin Fowler世界软件开发大师，在面向对象分析设计、UML、模式、xP和重构等领域都有卓越贡献。现为著名软件开发咨询公司Thoughtworks的首席科学家。他的多部著作《分析模式》、《UML精粹》和《企业应用架构模式》等都已经成为脍炙人口的经典。其他参编者Kent Beck软件开发方法学的泰斗，极限编程的创始人。他是Three Rivers lnslitule公司总裁，也是Agitar S0ftware的成员。John Brant和Don Roberts The Refactory公司的创始人。Refactory Browser的开发者。多年来一直从事研究重构的实践与理论。William Opdyke  目前在朗讯贝尔实验室工作，他写的关于面向对象框架的博士论文是重构方面的第一篇著名文章。

书籍目录

Chapter 1: Refactoring, a First Example  1The Starting Point　1The First Step in Refactoring　7Decomposing and Redistributing the Statement Method　8Replacing the Conditional Logic on Price Code with Polymorphism　34Final Thoughts　52Chapter 2: Principles in Refactoring　53Defining Refactoring　53Why Should You Refactor　55When Should You Refactor　57What Do I Tell My Manager　60Problems with Refactoring　62Refactoring and Design　66Refactoring and Performance　69Where Did Refactoring Come From　71Chapter 3: Bad Smells in Code (by Kent Beck and Martin Fowler)　75Duplicated Code　76Long Method　76Large Class　78Long Parameter List　78Divergent Change　79Shotgun Surgery　80Feature Envy　80Data Clumps　81Primitive Obsession　81Switch Statements　82Parallel Inheritance Hierarchies　83Lazy Class　83Speculative Generality　83Temporary Field　84Message Chains　84Middle Man　85Inappropriate Intimacy　85Alternative Classes with Different Interfaces　85Incomplete Library Class　86Data Class　86Refused Bequest　87Comments　87Chapter 4: Building Tests　89The Value of Self-testing Code　89The JUnit Testing Framework　91Adding More Tests　97Chapter 5: Toward a Catalog of Refactorings　103Format of the Refactorings　103Finding References　105How Mature Are These Refactorings　106Chapter 6: Composing Methods　109Extract Method　110Inline Method　117Inline Temp　119Replace Temp with Query　120Introduce Explaining Variable　124Split Temporary Variable　128Remove Assignments to Parameters　131Replace Method with Method Object　135Substitute Algorithm　139Chapter 7: Moving Features Between Objects　141Move Method　142Move Field　146Extract Class　149Inline Class　154Hide Delegate　157Remove Middle Man　160Introduce Foreign Method　162Introduce Local Extension　164Chapter 8: Organizing Data　169Self Encapsulate Field　171Replace Data Value with Object　175Change Value to Reference　179Change Reference to Value　183Replace Array with Object　186Duplicate Observed Data　189Change Unidirectional Association to Bidirectional　197Change Bidirectional Association to Unidirectional　200Replace Magic Number with Symbolic Constant　204Encapsulate Field　206Encapsulate Collection　208Replace Record with Data Class　217Replace Type Code with Class　218Replace Type Code with Subclasses　223Replace Type Code with State/Strategy　227Replace Subclass with Fields　232Chapter 9: Simplifying Conditional Expressions　237Decompose Conditional　238Consolidate Conditional Expression　240Consolidate Duplicate Conditional Fragments　243Remove Control Flag　245Replace Nested Conditional with Guard Clauses　250Replace Conditional with Polymorphism　255Introduce Null Object　260Introduce Assertion　267Chapter 10: Making Method Calls Simpler　271Rename Method　273Add Parameter　275Remove Parameter　277Separate Query from Modifier　279Parameterize Method　283Replace Parameter with Explicit Methods　285Preserve Whole Object　288Replace Parameter with Method　292Introduce Parameter Object　295Remove Setting Method　300Hide Method　303Replace Constructor with Factory Method　304Encapsulate Downcast　308Replace Error Code with Exception　310Replace Exception with Test　315Chapter 11: Dealing with Generalization　319Pull Up Field　320Pull Up Method　322Pull Up Constructor Body　325Push Down Method　328Push Down Field　329Extract Subclass　330Extract Superclass　336Extract Interface　341Collapse Hierarchy　344Form Template Method　345Replace Inheritance with Delegation　352Replace Delegation with Inheritance　355Chapter 12: Big Refactorings (by Kent Beck and Martin Fowler)　359Tease Apart Inheritance　362Convert Procedural Design to Objects　368Separate Domain from Presentation　370Extract Hierarchy　375Chapter 13: Refactoring, Reuse, and Reality (by William Opdyke)　379A Reality Check　380Why Are Developers Reluctant to Refactor Their Programs　381A Reality Check (Revisited)　394Resources and References for Refactoring　394Implications Regarding Software Reuse and Technology Transfer　395A Final Note　397References　397Chapter 14: Refactoring Tools (by Don Roberts and John Brant)　401Refactoring with a Tool　401Technical Criteria for a Refactoring Tool　403Practical Criteria for a Refactoring Tool　405Wrap Up　407Chapter 15: Putting It All Together (by Kent Beck)　409References　413List of Soundbites　417Index　419

章节摘录

插图：Any technical author has the problem of deciding when to publish. The earlieryou publish, the quicker people can take advantage of the ideas. However, people are always learning. If you publish half-baked ideas too early, the ideas canbe incomplete and even lead to problems for those who try to use them.   The basic technique of refactoring, taking small steps and testing often, hasbeen well tested over many years, especially in the Smalltalk community. So I'mconfident that the basic idea of refactoring is very stable.   The refactorings in this book are my notes about the refactorings I use. Ihave used them all. However, there is a difference between using a refactoringand boiling it down into the mechanical steps I give herein. In particular, youoccasionally see problems that crop up only in very specific circumstances. Icannot say that I have had a lot of people work from these steps to spot many of these kinds of problems. As you use the refactorings, be aware of what youare doing. Remember that like working with a recipe, you have to adapt the refactorings to your circumstances. If you run into an interesting problem, dropme an e-mail, and I'll try to pass on these circumstances for others.

编辑推荐

《重构:改善既有代码的设计(英文版)》：软件开发的不朽经典、生动阐述重构原理和具体做法、普通程序员进阶到编程高手必须修炼的秘笈。

用户评论 (总计12条)

•   经典著作，不适合学生或没有开发经验的人，有一定开发经验的人一定好好看看，真心挺好
•   序言沒有英文原文，只有中文譯文。
•   物流快，书面有折痕，不影响阅读
•   一直在重构自己的代码，也总结出很多方案， 看了福勒 才知道什么是集大成者
•   印象比较深的是:当对代码做修改感到困难时, 这时候需要重构
•   发货很快，隔天收到。内容自不必我说。可是书体有些折损，被折磨得像一本老书一样，可怜呀！不知道是不是运送过程中出现的问题，不过纸张和印刷字体很赞！能不能保证运送的质量呀？每次收到的书都会多少被弄坏！
•   前几页是中文，感觉怪怪的，不过总体来说，还是不错！本人认为这本书是很值得去细看，去思考的。
•   书的内容不错，除了有点坑，在描述上的需要，会比较重复的打印一页页代码。在设计模式熟悉了后，结合工作经验会有不同的领会。
•   前段时间因为公司需要code refactorying，于是购买了此书，读后很有收获。有些思想在我们项目重构中也用到。个人认为:这是不仅是一本技术书，更是一本编程思想书。找时间还是要细细品味一下，学以致用，哈哈
•   一直都很追求代码的优雅性，也在实践中用了一些重构的方法，看到这本书，算是为实践找到了理论依据，很好！例子明白、有针对性，英文用词易懂、不生僻！
•   书，现在我只看了前面一部分，但我感觉我看的很爽，尤其是Martin Folwer，他写的东西，我看起来不会头疼（英文书中），有些英文书看起来很晦涩，而他的我就感觉很流畅。还有就是这真是一本很不错的书。
•   很好 质量还不错