标题：重构：改善既有代码的设计
图书信息
重构：改善既有代码的设计  [1]定　价：￥69.00 
库　存：有货，可送至全国作　者：（美）福勒 著
出 版 社：人民邮电出版社
出版时间：2010-11-1
开　本：16开
I S B N：9787115239143
内容简介
本书清晰揭示了重构的过程，解释了重构的原理和最佳实践方式，并给出了何时以及何地应该开始挖掘代码以求改善。书中给出了70多个可行的重构，每个重构都介绍了一种经过验证的代码变换手法的动机和技术。本书提出的重构准则将帮助你一次一小步地修改你的代码，从而减少了开发过程中的风险。
本书适合软件开发人员、项目管理人员等阅读，也可作为高等院校计算机及相关专业师生的参考读物。 
作者简介 Martin Fowler是一位独立咨询顾问，他运用对象技术解决企业问题已经超过十年。他的顾问领域包括健康管理、金融贸易，以及法人财务。他的客户包括Chrysler，Citibank，UK National Health Service，AndersenConsulting，NetscapeCommunications。此外Fowler也是objects、UML、patterns技术的一位合格讲师，他是《AnalysisPatterns》和《UML Distilled》的作者。
编辑推荐
“这《重构:改善既有代码的设计》之于重构就相当于韵谱之于作诗。一个翻着韵书作诗的诗人一定是蹩脚的，但好的诗人却要对那109个韵部了然于胸；同样，一个好的程序员要求能够主动自然地重构代码，虽不应翻着重构手册干活，但需对《重构:改善既有代码的设计》中提到的70多个重构方法成竹在胸。然而，在达到这一境界之前，需要不断的实践和经验积累，并且要先读读Fowler的这《重构:改善既有代码的设计》。” 
“一口气读完了这《重构:改善既有代码的设计》，感觉书中作者对代码的整理不像是一种技术，更像是一种艺术。” 
“太经典了，看这《重构:改善既有代码的设计》真有醍醐灌顶的感觉。” 
“处于金字塔顶部的书不多，而这一《重构:改善既有代码的设计》恰恰就是，很幸运我看到了它。” 
“这《重构:改善既有代码的设计》本质上是向我们推荐了一种优秀的编程习惯和编程态度。在领会《重构:改善既有代码的设计》思想的同时，我们也应该培养一种精益求精的工作态度，探索一条更适合自己的重构道路。” 
“今年已经看了两遍，每次都有很大的收获。特别喜欢其中对其他章节的索引，当你把它作为一个手边随时翻阅的参考书看时，它不知不觉引导你读了很多内容，问题也在不知不觉中有了求解思路，最终得以解决。” 
“不要写完代码就束之高阁，适当地优化代码结构，能够为以后的开发带来许多方便，这《重构:改善既有代码的设计》就向你介绍了这方面的技巧，说得非常详细。” 
“程序几乎离不开重构，但如何更加迅速有效地重构却一直没有系统性的指导。《重构:改善既有代码的设计》就是这样的经典巨著，有了它，重构不再烦琐！”
软件开发的不朽经典，生动阐述重构原理和具体做法，普通程序员进阶到编程高手必须修炼的秘笈。
重构，一言以蔽之，就是在不改变外部行为的前提下，有条不紊地改善代码。多年前，正是《重构:改善既有代码的设计》原版的出版，使重构终于从编程高手们的小圈子走出，成为众多普通程序员日常开发工作中不可或缺的一部分。《重构:改善既有代码的设计》也因此成为与《设计模式》齐名的经典著作，被译为中、德、俄、日等众多语言，在世界范围内畅销不衰。
《重构:改善既有代码的设计》凝聚了软件开发社区专家多年摸索而获得的宝贵经验，拥有不因时光流逝而磨灭的价值。今天，无论是重构本身，业界对重构的理解，还是开发工具对重构的支持力度，都与《重构:改善既有代码的设计》最初出版时不可同日而语，但书中所蕴涵的意味和精华，依然值得反复咀嚼，而且往往能够常读常新。
作者简介
作者：(美国)福勒(Martin Fowler) 译者：熊节
Martin Fowler，世界软件开发大师，在面向对象分析设计、UML、模式、XP和重构等领域都有卓越贡献，现为著名软件开发咨询公司ThoughtWorks的首席科学家。他的多部著作《分析模式》、《UML精粹》和《企业应用架构模式》等都已经成为脍炙人口的经典。
熊节，ThoughtWorks中国公司的高级咨询师、架构师和项目经理，在大型企业应用及互联网应用的架构和管理方面拥有丰富经验。作为敏捷方法学顾问和重构专家，他拥有在各种技术平台、编程语言、软件形态的项目中实施重构的丰富经验，并曾主持极具挑战性的超大规模电信软件系列重构工作。
目录
第1章 重构，第一个案例1.1 起点1
1.2 重构的第一步7
1.3 分解并重组statement()8
1.4 运用多态取代与价格相关的条件逻辑34
1.5 结语52
第2章 重构原则2.1 何谓重构53
2.2 为何重构55
2.3 何时重构57
2.4 怎么对经理说60
2.5 重构的难题62
2.6 重构与设计66
2.7 重构与性能69
2.8 重构起源何处71
第3章 代码的坏味道3.1 DuplicatedCode（重复代码）76
3.2 LongMethod（过长函数）76
3.3 LargeClass（过大的类）78
3.4 LongParameterList（过长参数列）78
3.5 DivergentChange（发散式变化）79
3.6 ShotgunSurgery（霰弹式修改）80
3.7 FeatureEnvy（依恋情结）80
3.8 DataClumps（数据泥团）81
3.9 PrimitiveObsession（基本类型偏执）81
3.10 SwitchStatements（switch惊悚现身）82
3.11 ParallelInheritanceHierarchies（平行继承体系）83
3.12 LazyClass（冗赘类）83
3.13 SpeculativeGenerality（夸夸其谈未来性）83
3.14 TemporaryField（令人迷惑的暂时字段）84
3.15 MessageChains（过度耦合的消息链）84
3.16 MiddleMan（中间人）85
3.17 InappropriateIntimacy（狎昵关系）85
3.18 AlternativeClasseswithDifferentInterfaces（异曲同工的类）85
3.19 IncompleteLibraryClass（不完美的库类）86
3.20 DataClass（纯稚的数据类）86
3.21 RefusedBequest（被拒绝的遗赠）87
3.22 Comments（过多的注释）87
第4章 构筑测试体系4.1 自测试代码的价值89
4.2 JUnit测试框架91
4.3 添加更多测试97
第5章 重构列表5.1 重构的记录格式103
5.2 寻找引用点105
5.3 这些重构手法有多成熟106
第6章 重新组织函数6.1 ExtractMethod（提炼函数）110
6.2 InlineMethod（内联函数）117
6.3 InlineTemp（内联临时变量）119
6.4 ReplaceTempwithQuery（以查询取代临时变量）120
6.5 IntroduceExplainingVariable（引入解释性变量）124
6.6 SplitTemporaryVariable（分解临时变量）128
6.7 RemoveAssignmentstoParameters（移除对参数的赋值）131
6.8 ReplaceMethodwithMethodObject（以函数对象取代函数）135
6.9 SubstituteAlgorithm（替换算法）139
第7章 在对象之间搬移特性7.1 MoveMethod（搬移函数）142
7.2 MoveField（搬移字段）146
7.3 ExtractClass（提炼类）149
7.4 InlineClass（将类内联化）154
7.5 HideDelegate（隐藏“委托关系”）157
7.6 RemoveMiddleMan（移除中间人）160
7.7 IntroduceForeignMethod（引入外加函数）162
7.8 IntroduceLocalExtension（引入本地扩展）164
第8章 重新组织数据8.1 SelfEncapsulateField（自封装字段）171
8.2 ReplaceDataValuewithObject（以对象取代数据值）175
8.3 ChangeValuetoReference（将值对象改为引用对象）179
8.4 ChangeReferencetoValue（将引用对象改为值对象）183
8.5 ReplaceArraywithObject（以对象取代数组）186
8.6 DuplicateObservedData（复制“被监视数据”）189
8.7 ChangeUnidirectionalAssociationtoBidirectional（将单向关联改为双向关联）197
8.8 ChangeBidirectionalAssociationtoUnidirectional（将双向关联改为单向关联）200
8.9 ReplaceMagicNumberwithSymbolicConstant（以字面常量取代魔法数）204
8.10 EncapsulateField（封装字段）206
8.11 EncapsulateCollection（封装集合）208
8.12 ReplaceRecordwithDataClass（以数据类取代记录）217
8.13 ReplaceTypeCodewithClass（以类取代类型码）218
8.14 ReplaceTypeCodewithSubclasses（以子类取代类型码）223
8.15 ReplaceTypeCodewithState/Strategy（以State/Strategy取代类型码）227
8.16 ReplaceSubclasswithFields（以字段取代子类）232
第9章 简化条件表达式9.1 DecomposeConditional（分解条件表达式）238
9.2 ConsolidateConditionalExpression（合并条件表达式）240
9.3 ConsolidateDuplicateConditionalFragments（合并重复的条件片段）243
9.4 RemoveControlFlag（移除控制标记）245
9.5 ReplaceNestedConditionalwithGuardClauses（以卫语句取代嵌套条件表达式）250
9.6 ReplaceConditionalwithPolymorphism（以多态取代条件表达式）255
9.7 IntroduceNullObject（引入Null对象）260
9.8 IntroduceAssertion（引入断言）267
第10章 简化函数调用10.1 RenameMethod（函数改名）273
10.2 AddParameter（添加参数）275
10.3 RemoveParameter（移除参数）277
10.4 SeparateQueryfromModifier（将查询函数和修改函数分离）279
10.5 ParameterizeMethod（令函数携带参数）283
10.6 ReplaceParameterwithExplicitMethods（以明确函数取代参数）285
10.7 PreserveWholeObject（保持对象完整）288
10.8 ReplaceParameterwithMethods（以函数取代参数）292
10.9 IntroduceParameterObject（引入参数对象）295
10.10 RemoveSettingMethod（移除设值函数）300
10.11 HideMethod（隐藏函数）303
10.12 ReplaceConstructorwithFactoryMethod（以工厂函数取代构造函数）304
10.13 EncapsulateDowncast（封装向下转型）308
10.14 ReplaceErrorCodewithException（以异常取代错误码）310
10.15 ReplaceExceptionwithTest（以测试取代异常）315
第11章 处理概括关系11.1 PullUpField（字段上移）320
11.2 PullUpMethod（函数上移）322
11.3 PullUpConstructorBody（构造函数本体上移）325
11.4 PushDownMethod（函数下移）328
11.5 PushDownField（字段下移）329
11.6 ExtractSubclass（提炼子类）330
……
第12章 大型重构第13章 重构，复用与现实第14章 重构工具第15章 总结参考书目413 
要点列表417 
索引419
序言
第一次听到“重构”这个词，是在2001年10月。在当时，它的思想足以令我感到震撼。软件自有其美感所在。软件工程希望建立完美的需求与设计，按照既有的规范编写标准划一的代码，这是结构的美；快速迭代和RAD颠覆“全知全能”的神话，用近乎刀劈斧砍（crack）的方式解决问题，在混沌的循环往复中实现需求，这是解构的美；而Kent Beck与Martin Fowler两人站在一起，以XP那敏捷而又严谨的方法论演绎了重构的美——我不知道是谁最初把refactoring一词翻译为“重构”，或许无心插柳，却成了点睛之笔。 
我一直是设计模式的爱好者。曾经在我的思想中，软件开发应该有一个“理想国”——当然，在这个理想国维持着完美秩序的，不是哲学家，而是模式。设计模式给我们的，不仅仅是一些具体问题的解决方案，更有追求完美“理型”的渴望。但是，Joshua Kerievsky在那篇著名的《模式与XP》（收录于《极限编程研究》一书）中明白地指出：在设计前期使用模式常常导致过度工程（over-engineering）。这是一个残酷的现实，单凭对完美的追求无法写出实用的代码，而“实用”是软件压倒一切的要素。从一篇《停止过度工程》开始，Kerievsky撰写了“Refactoring to Patterns”系列文章。这位犹太人用他民族性的睿智头脑，敏锐地发现了软件的后结构主义道路。而让设计模式在飞速变化的网络时代重新闪现光辉的，又是重构的力量。 
在一篇流传甚广的帖子里，有人把《重构》与《设计模式》并列为“Java行业的圣经”。在我看来这种并列其实并不准确。实际上，尽管我如此喜爱这本《重构》，但自从完成翻译之后，就再也没有读过它。不，不是因为我已经对它烂熟于心，而是因为重构已经变成了我的另一种生活方式，变成了我每天的“面包与黄油”，变成了我们整个团队的空气与水，以至于无需再到书中寻找任何“神谕”。而《设计模式》，我倒是放在手边时常翻阅，因为总是记得不那么真切。