《重构与模式》由会员分享，可在线阅读，更多相关《重构与模式（11页珍藏版）》请在金锄头文库上搜索。
1、译者序设计模式代表了传统的软件开发思想：好的设计会产生好的软件，因此在实际 开发之前，值得花时间去做一个全面而细致的设计。重构代表了敏捷软件开发的 浪潮： 软件并不是在一开始就可以设计得完美无缺的，因此可以先进行实际开 发，然后通过对代码不断的进行小幅度的修改来改善其设计。二者从不同角度阐 述了设计的重 要性。重构是实现设计模式的一种手段，设计模式往往也是重构的目的。Martin Fowler 序重构其实就是循序渐进的进行较大的修改前言重构：改善既有代码设计的过程 模式：针对反复出现的问题的经典解决方案 建议使用模式来改善既有的设计，要优于在新的设计早期使用模式。建议通过 一系列低层次的设计转
2、换，也就是重构，来应用模式，改进设计。第 1 章 本书的写作缘由应该通过重构实现模式、趋向模式和去除模式(refac to ring to, t owards, and away from pattern)，而不是在预先设计中使用模式，也不再过早的在代码中加 入模式。这技能避免过度设计，又不至于设计不足。过度设计：代码的灵活性和复杂性超出所需。 项目中每人负责一块会使每个人都在自己的小天地工作而不关注别人是否已 经完成了自己所需，最终导致大量重复代码。设计不足产生的原因： 程序员没有时间，没有抽出时间，或者时间不允许进行重构 程序员在何为好的软件设计方面知识不足 程序员被要求在既有系统中快速的
3、添加新功能 程序员被迫同时进行太多项目长期的设计不足，会使软件开发节奏变成“快，慢，更慢”，可能的后果是： 系统的 1.0 版本很快就交付了，但是代码质量很差系统的 2.0 版本也交付了，但质量低劣的代码使我们慢下来 在企图交付未来版本时，随着劣质代码的倍增，开发速度也越来越慢，最后 人们对系统、程序员乃至使大家陷入这种境地的整个过程都失去了信心到了4.0 版本时或者之后，我们意识到这样肯定不行，开始考虑推倒重来测试驱动开发和持续重构提供了一种精益、迭代和训练有素的编程风格，能够最大程度的有张有弛，提高生产率。“迅速而又从容不迫”使用测试驱动开发和持续重构有助于：保持较低的缺陷数量大胆的进行重
4、构得到更加简单、更加优秀的代码编程时没有压力模式和重构之间存在着天然联系，模式是你想达到的目的地，而重构则是从其 他地方抵达这个目的地的条条道路。第 2 章 重构重构：保持行为的转换。重构是一种对软件内部结构的改善，目的是在不改变 软件的可见行为的情况下，使其更易理解，修改成本更低。重构过程：去除重复、简化复杂逻辑和澄清模糊的代码。 重构最好持续而不是分阶段的进行，只要看到代码需要改善，就改善它。 重构实践必须和谐的适应业务上的轻重缓急。重构的动机： 使新代码的增加更容易 改善既有代码的设计 对代码理解更透彻 提高编程的趣味性所有优秀的设计都是不断修改而成的，修改意味着重新审视 任何傻瓜都会编
5、写计算机能理解的代码，好的程序员能够编写人能够理解的代 码。要保持代码清晰，必须持续的去除重复，简化和澄清代码。决不能容忍代码中 的脏乱，决不能倒退到坏习惯中去。清晰的代码能产生更好的设计，而更好的设 计将使开发过程更加迅速，从而使客户和程序员皆大欢喜。请保持代码的清晰吧！绿条就像一个陀螺仪，能够使我们不偏离航线，如果红条显示的时间太长 超过几分钟，我就知道自己采取的步骤不够小。这时应该返工，重新开始。采取 更小、更安全的步骤比采取更大的步骤更能快速达到目标。使用重构的技术语言和大多数管理人员交流，效果都不好，经理很难批准你花 一些时间进行所谓的重构或改善设计。应该采用更好的术语“设计欠账”包
6、括 “欠账的滞纳金”术语和管理层沟通会取得更佳的效果。进展太快对所有人都没有好处 不能将框架组合应用组隔离开，应该成立一个组，并用实际的需求驱动框架的 持续进化。这无论对应用还是对框架进化都是很有好处的。一般而言，设计模式的代码生成工具提供的是饮鸩止渴之道，很容易使代码过 度设计。第3 章模式在预先设计对赢得合同非常关键时，仍然很值得采用，其他情况下请审慎。第4 章代码坏味常见的设计问题都出重复、不清晰、复杂的代码重复代码类层次中不同子类里存在明显或微妙的重f形成Templa te Met hod子类中的方法除了对象创建之外其他实现方法都类似f用Fac tory Met hod 引入多态创建f
7、使用Templa te Met hod去除更多重复构造函数包含重复代码f链构造函数单独的代码处理一个对象或者一组对象fComposite替换类层次多个子类都实现了自己的Composite,而且实现可能完全相同f提取 Composite对象处理方法的区别仅在于接口不同f通过Adapter统一接口条件逻辑处理空对象，而且相同的空逻辑在整个系统中都是重复的f引入 Null Object方法过长短方法更容易逻辑共享，更容易理解，更容易扩展维护 方法应该在10行以内，大多数方法应该在15行。如果系统的大多数方法 都比较小，可以有少数的方法稍大一些，只要它们容易理解并且不包含重复代码不用担心短方法造成的性
8、能问题：优秀的设计人员都不会对代码进行不成熟 的优化；性能剖析工具证明将许多小方法串起来性能开销微乎其微；即使剖桥遇 到性能问题，可以通过重构来改进性能，无需放弃小方法原则方法过长f用组合方法重构将其分解为Composed Met hod f若正在转换的 Composed Met hod要将某个信息累加到一个公共变量中？ f将聚集操作搬移到 Collecting Parameter大的 switch 分派Command采用swi tch从接口不同的许多类收集数据f将聚集操作搬移到Vis tor大方法包含了算法的许多版本和运行时用来选择版本的条件逻辑 fStrategy条件逻辑过复杂条件逻辑控制
9、的是一种计算的几个变形fS tra tegy条件逻辑控制执行类的核心行为之外某个特殊行为f将装饰功能搬移到 Decorator控制对象状态转换一State处理空操作，并且系统中有重复相同的空条件逻辑f引入Null Object基本类型迷恋非类型安全的基本类型（客户可以赋予它不安全或不正确的值）控制类中的 逻辑f用类替换基本类型，得到类型安全并且能够扩展新行为的代码控制对象状态转换使用了复杂条件逻辑的基本类型fState，用许多类表示 每个状态和简化的状态转换逻辑控制算法运行的条件逻辑非常复杂fS tra tegy 隐式创建了基本类型的树结构f Composi te 如果有许多方法支持多个基本类
10、型值的组合，那么就可能存在隐式语言 fInterpreter基本值类型只是为了提供类核心职责的装饰f Decora tor过于原始，对客户代码的用处不大的Compositef用Builder圭寸装Composite 不恰当的暴露让客户看到不太重要或有间接重要性的代码会增加复杂度Factory 可以很好的处理公开构造函数的暴露 解决方案蔓延许多类中都有用来完成某些职责的代码或数据，通常由快速的功能堆砌 造成对象创建职责的蔓延可以通过Factory解决 异曲同工的类两个相似的类却有不同的接口若对代码有可控权f重构为共享一个公共接口若无代码控制权（如3Party代码）fAdapter冗赘类（rong
11、zhui ）类如果功能有限，缺乏存在价值，就应该删除内联Single ton是快速而优雅的Single ton实现 类过大如果类中存在过多的字段，往往说明类的职责太多switch 或 if 条件调度f Command状态改变条件语句一State隐式语言（模仿某种语言的代码）finterpreter分支语句switch 或 if 条件调度f Command聚集操作fVisi tor组合爆炸Interpreter怪异解决方案 在同一系统中用不同的方式解决同一问题，称之为怪异或者不一致的解 决方案第5 章 模式导向的重构目录第6 章 创建6.1 用 Creating Method 替换构造函数 当类
12、中有多个构造函数，因此很难决定在开发期间用哪一个时，可以用能够说 明意图的返回对象实例的 Creation Method 替换构造函数动机：Creation Method 类中的一个静态或者非静态的负责实例化类的新实例方 法。因Creating Method命名没有限制，所以可以取最能表达所创建对象的名字。类中有太多构造函数f提炼类或者提炼子类 或者用CreationMethod替换构 造函数来澄清构造函数的意图优缺点：+ 比构造函数能够更好的表达所创建的实例种类+ 避免了构造函数的局限，比如两个构造函数的参数数目和类型不能相同+ 更容易发现无用的创建代码-创建方式是非标准的，有的用new实例
13、化，而有的用Creation Method实例 化变体：不需要为每个对象的配置都设立一个Crea tion Met hod，非必要情况下可以添 加参数来减少 Creation Method 的数量当 Creation Method 过多的分散了类的主要职责是，应该考虑将相关的 Creation Method 重构为一个 Factory6.2 将创建知识搬移到 Factory 当用来实例化一个类的数据和代码在多个类中到处都是时，可以讲有关创建的知识搬移到一个 Factory 中动机： 创建蔓延将创建的职责放在了不应该承担对象创建任务的类中，是解决方 案蔓延中的一种，一般是之前的设计问题导致。使用
14、一个Factory类封装创建逻辑和客户代码的实例化选项，客户可以告诉 Factory 实例如何实例化一个对象，然后用同一个 Factory 实例在运行时执行实 例化。Factory不需要用具体类专门实现，可以使用一个接口定义Factory,然后让 现有的类实现这个接口。如果Factory中创建逻辑过于复杂，应将其重构为Abstract Factory，客户 代码可以配置系统使用某个 ConcreteFactory（AbstractFactory 的一个具体实 现）或者默认的 ConcreteFactory。只有确实改进了代码设计，或者无法直接进行实例化时才有足够的理由进行 Factory 重构
15、优缺点：+ 合并创建逻辑和实例化选项+ 将客户代码与创建逻辑解耦- 如果可以直接实例化，会使设计复杂化6.3 用 Factory 封装类 当直接实例化处在同一包结构中、实现统一接口的多个类。可以把类的构造函数声明为非公共的，并通过Factory来创建它们的实例动机：可以通过 Factory 将一组客户并不需关心的子类屏蔽到包内部。如果类共享一个通用的公共接口、共享相同的超类、并且处在同一包结构中， 该重构可能有用。优缺点：+ 通过意图导向的 Creation Method 简化了不同种类实例的创建+ 通过隐藏不需要公开的类减少了包的“概念重量”+ 帮助严格执行“面向接口编程，而不是面向实现”这一格言- 当需要创建新种类的实例时，必须更新 Creation Method- 当客户只能获得 Factory 的二进制代码而无法获得源码时，对 Factory 的定 制将受到限制6.4 用 Factory Method 引入多态创建当一个层次中的类都相似的实现一个方法，只是对象创建的步骤不同时，可以 创建调用 Factory Method 来处理实例化方法的唯一超类版本动机：Factory Method 是 OOP 中最常见的模式，因其提供了多台创建对象的方法使用 Factor
