（繁体版）
英文版勘误 ：http://www.refactoring.com/errata.html
侯捷推荐相关书籍：《Refactoring to Patterns》,《Design Patterns》
□中译书名：重构 ─ 改善既有程式的设计
□适合对象：高阶程式员
□内容特色：将如何重构既有系统的步骤系统化地加以整理和描述。使用Java语言。
□制作特色：含 index，网片输出，精装，红蓝白书签丝条。
开放档案如下：（请注意，预览品与正式出版品之间可能会有微小差异）
| 档名 | 内容 | 大小 bytes |
| refactoring-ch1-ch6.pdf 不需密码即可开启。 档案含书签（目录连结） 请注意：本书之所有 refactoring name 和 bad smells 皆保留原文不译。 |
译序 by 侯捷 译序 by 熊节 目录 原序 前言 1~6章 索引 |
2,151,797 |
| efile-refactoring-chap01.zip |
第一章 程式源码（by 侯捷） |
9,855 |
如欲下载，请将滑鼠移至上述 hyperlink，按右键，再选【另存目标...】即可。
译序by侯捷 看过铁路道班工人吗？提着手持式砸道机，机身带着钝钝扁扁的钻头，在铁道上、枕木间卖力地「砍劈钻凿」。他们在做什麽？他们在使路基上的碎石块（道碴）因持续剧烈的震动而翻转方向、滑动位置，甚至震碎为更小石块填满缝隙，以求道碴更紧密契合，提供铁道更安全更强固的体质。
当「重构」（
refactoring）映入眼帘，我的大脑牵动「道班工人+电动砸道机+枕木道碴」这样一幅联想画面。「重构」一词非常清楚地说明了它自身的意义和价值：在不破坏可察功能的前提下，藉由搬移、提炼、打散、凝聚┅，改善事物的体质。很多人认同这样一个信念：「非常的建设需要非常的破坏」，但是现役的应用软体、构筑过半的专案、运转中的系统，容不得推倒重来。这时候，在不破坏可察功能的前提下改善体质、强化当前的可读性、为将来的扩充性和维护性做准备、乃至於在过程中找出潜伏的「臭虫」，就成了大受欢迎的稳步前进的良方。做为一个程式员，任谁都有看不顺眼手上程式码的经验
程式码来自你邻桌那个菜鸟，或三个月前的自己。面临此境，有人选择得过且过；然而根据我对「程式员」人格特质的了解，更多人盼望插手整顿。挽起袖子剑及履及，其勇可嘉其虑未缜。过去或许不得不暴虎凭河，忍受风险。现在，有了严谨的重构准则和严密的重构手法，「稳定中求发展」终於有了保障。是的，把重构的概念和想法逐一落实在严谨的准则和严密的手法之中，正是这本《
Refactoring》的最大贡献。重构?! 呵呵，上进的程式员每天的进行式，从来不新鲜，但要强力保证「维持程式原有的可察功能，不带进新臭虫」，重构就不能是一项靠着天份挥洒的艺术，必须是一项工程。 ■我对本书的看法初初阅读本书，屡屡感觉书中所列的许多重构目标过於平淡，重构步骤过於琐屑。这些我们平常也都做、习惯大气挥洒的动作，何必以近乎枯燥的过程小步前进？然後，渐渐我才体会，正是这样的小步与缓步前进，不过激，不躁进，再加上完整的测试配套（是的，测试之於重构极其重要），才是「不带来破坏，不引入臭虫」的最佳保障。我个人其实不敢置信有谁能够乖乖地按步遵循实现本书所列诸多被我（从人的角度）认为平淡而琐屑的重构步骤。我个人认为，本书的最大价值，除了呼 对软体品质的追求态度，以及对重构「工程性」的认识，最终最重要的价值还在於：建立起吾人对於「目前和未来之自动化重构工具」的基本理论和实作技术上的认识与信赖。人类眼中平淡琐屑的步骤，正是自动化重构工具的基础。机器缺乏人类的「大局观」智慧，机器需要的正是切割为一个一个极小步骤的指令。一板一眼，一次一点点，这正是机器所需要的，也正是机器的专长。
本书第
14章提到，Smalltalk开发环境已含自动化重构工具。我并非Smalltalk guy，我没有用过这些工具。基於技术的飞快滚动（或我个人的孤陋寡闻），或许如今你已经可以在Java, C++ 等物件导向编程环境中找到这一类自动化重构工具。软体技术圈内，重构（
refactoring）常常被拿来与设计范式（design patterns）并论。书籍市场上，《Refactoring》也与《Design Patterns》齐名。GoF曾经说『设计范式为重构提供了目标』，但本书作者Martin亦言『本书并没有提供助你完成所有知名范式的重构手法，甚至连 GoF 的23个知名范式都没有能够全部涵盖。』我们可以从这些话中理解技术的方向，以及书籍所反映的局限。我并不完全赞同Martin所言『哪怕你手上有一个糟糕的设计或甚至一团混乱，你也可以藉由重构将它加工成设计良好的程式码。』但我十分同意Martin说『你会发现所谓设计不再是一切动作的前提，而是在整个开发过程中逐渐浮现出来。』我比较担心，阅历不足的程式员在读过本书後可能发酵出「先动手再说，死活可重构」的心态，轻忽了事前优秀设计的重要性。任何技术上的说法都必须有基本假设；虽然重构（或更向上说XP，eXtreme Programming）的精神的确是「不妨先动手」，但若草率行事，代价还是很高的。重型开发和轻型开发各有所长，各有应用，世间并无万应灵药，任何东西都不能极端。过犹不及，皆不可取！当然，「重构工程」与「自动化重构工具」可为我们带来相当大幅度的软体品质提升，这一点我毫无异议，并且非常期待J 。
■关於本书制作本书在翻译与制作上保留了所有坏味道（
bad smell）、重构（refactoring）、设计范式（design patterns）的英文名称，并表现以特殊字型；只在封面内页、目录、小节标题中相应地给出一个根据字面或技术意义而做的中文译名。各种「坏味道」名称尽量就其意义选用负面字眼，如泥团、夸夸、过长、过大、过多、情结、偏执、惊悚、狎昵、纯稚、冗员┅。这些其实都是助忆之用，与茶馀饭後的谈资（以及读者批评的根据J ）。原书各小节并无序号。为便利叁考、检索或讨论时的方便，我为译本加上了序号。
本书保留相当份量的英文术语，时而英中并陈（英文为主，中文为辅）。这麽做的考量是，本书读者不可能不知道
class, final, reference, public, package┅这些简短的、与Java编程息息相关的用词。另一方面，我确实认为，中文书内保留经过挑选的某些英文术语，有利於整体阅读效果。两个需要特别说明的用词是
Java编程界惯用的 "field" 和 "method"。它们相当於C++ 的 "data member" 和 "member function"。由於出现次数实在频繁，为降低中英夹杂程度，我把它们分别译为「栏位」和「函式」 如果将 "method" 译为「方法」，恐怕术语突出性不高。此外，本书将「创造建立新物件」的 "create" 动作译为「创建」。「static栏位与instance栏位」、「reference物件与value物件」等等则保留部分英文，并选用如上的特殊字型。凡此总总，相信一进入书中您很快可以感受本书术语风格。本书还有诸多地方采中英并陈（中文为主，英文为辅）方式，意在告诉读者，我们（译者）深知自己的不足与局限，惟恐造成您对中译名词的误解或不习惯，所以附上原文。
中文版（本书）已将英文版截至
2003/06/18为止之勘误，修正於纸本。 ■一点点感想Martin Fowler表现於原书的写作风格是：简洁，爱用代名词和略称。这使得读者往往需要在字面上揣度推敲。我期盼（并相信）经过技术意义的反刍、中英术语的并陈、中文表述的努力，中文版（本书）在阅读时间和理解时间和记忆深度上，较之英文版，能够为以华文为母语的读者提高10倍以上的成效。
本书由我和熊节先生合译。熊节负责第一个
pass，我负责後继工作。中文版（本书）为读者带来的阅读和理解上的效益，熊节居於首功 虽说做的是第一个pass，我从初稿品质便可看出他多次反覆推敲和文字琢磨的刻痕。至於整体风格、中英术语的选定、版面的呈现、乃至於全盘技术内涵的表现，如果有任何差错，责任都是我的J 。做为一个资讯技术教育者，以及一个资讯技术传播者，我在超过
10年的写译历程中，观察了不同级别的技术书品在读书市场上的兴衰起伏。这些适可反映大环境下技术从业人员及学子们的某些面向和取向。我很高兴看到我们的中文技术书籍（着译皆含）从早期盈盈满满的初阶语言用书，逐渐进化到中高阶语言用书、作业系统、技术内核、程式库/框架、再至设计/分析、软体工程。我很高兴看到这样的变化。我很高兴看到《Design Patterns》、《Refactoring》、《Agile┅》、《UML┅》、《XP┅》之类的书在中文书籍市场中现身，并期盼它们有丰富的读者。中文版（本书）支援网站有一个「术语
英中繁简」对照表。如果您有需要，欢迎访问，网址如下，并欢迎给我任何意见。谢谢。 侯捷 2003/06/18 于台湾.新竹jjhou@jjhou.com（电子邮箱）
http://www.jjhou.com（繁体）（术语对照表http://www.jjhou.com/terms.htm）
http://jjhou.csdn.net（简体）（术语对照表http://
jjhou.csdn.net/terms.htm）
英文版目录
1. Refactoring, a First Example.
The Starting Point.
The First Step in Refactoring.
Decomposing and Redistributing the Statement Method.
Replacing the Conditional Logic on Price Code with Polymorphism.
Final Thoughts.
2. Principles in Refactoring.
Defining Refactoring.
Why Should You Refactor?
When Should You Refactor?
What Do I Tell My Manager?
Problems with Refactoring.
Refactoring and Design.
Refactoring and Performance.
Where Did Refactoring Come From?
3. Bad Smells in Code.
Duplicated Code.
Long Method.
Large Class.
Long Parameter List.
Divergent Change.
Shotgun Surgery.
Feature Envy.
Data Clumps.
Primitive Obsession.
Switch Statements.
Parallel Inheritance Hierarchies.
Lazy Class.
Speculative Generality.
Temporary Field.
Message Chains.
Middle Man.
Inappropriate Intimacy.
Alternative Classes with Different Interfaces.
Incomplete Library Class.
Data Class.
Refused Bequest.
Comments.
4. Building Tests.
The Value of Self-testing Code.
The JUnit Testing Framework.
Adding More Tests.
5. Toward a Catalog of Refactorings.
Format of the Refactorings.
Finding References.
How Mature Are These Refactorings?
6. Composing Methods.
Extract Method.
Inline Method.
Inline Temp.
Replace Temp with Query.
Introduce Explaining Variable.
Split Temporary Variable.
Remove Assignments to Parameters.
Replace Method with Method Object.
Substitute Algorithm.
7. Moving Features Between Objects.
Move Method.
Move Field.
Extract Class.
Inline Class.
Hide Delegate.
Remove Middle Man.
Introduce Foreign Method.
Introduce Local Extension.
8. Organizing Data.
Self Encapsulate Field.
Replace Data Value with Object.
Change Value to Reference.
Change Reference to Value.
Replace Array with Object.
Duplicate Observed Data.
Change Unidirectional Association to Bidirectional.
Change Bidirectional Association to Unidirectional.
Replace Magic Number with Symbolic Constant.
Encapsulate Field.
Encapsulate Collection.
Replace Record with Data Class.
Replace Type Code with Class.
Replace Type Code with Subclasses.
Replace Type Code with State/Strategy.
Replace Subclass with Fields.
9. Simplifying Conditional Expressions.
Decompose Conditional.
Consolidate Conditional Expression.
Consolidate Duplicate Conditional Fragments.
Remove Control Flag.
Replace Nested Conditional with Guard Clauses.
Replace Conditional with Polymorphism.
Introduce Null Object.
Introduce Assertion.
10. Making Method Calls Simpler.
Rename Method.
Add Parameter.
Remove Parameter.
Separate Query from Modifier.
Parameterize Method.
Replace Parameter with Explicit Methods.
Preserve Whole Object.
Replace Parameter with Method.
Introduce Parameter Object.
Remove Setting Method.
Hide Method.
Replace Constructor with Factory Method.
Encapsulate Downcast.
Replace Error Code with Exception.
Replace Exception with Test.
11. Dealing with Generalization.
Pull Up Field.
Pull Up Method.
Pull Up Constructor Body.
Push Down Method.
Push Down Field.
Extract Subclass.
Extract Superclass.
Extract Interface.
Collapse Hierarchy.
Form Template Method.
Replace Inheritance with Delegation.
Replace Delegation with Inheritance.
12. Big Refactorings.
Tease Apart Inheritance.
Convert Procedural Design to Objects.
Separate Domain from Presentation.
Extract Hierarchy.
13. Refactoring, Reuse, and Reality.
A Reality Check.
Why Are Developers Reluctant to Refactor Their Programs?
A Reality Check (Revisited).
Resources and References for Refactoring.
Implications Regarding Software Reuse and Technology Transfer.
A Final Note.
References.
14. Refactoring Tools.
Refactoring with a Tool.
Technical Criteria for a Refactoring Tool.
Practical Criteria for a Refactoring Tool.
Wrap Up.
15. Putting It All Together.
References.
List of Soundbites.
List of Refactorings.
Index