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