《重构与模式》读书笔记

Posted on Edited on In Views:

refactor_to_pattern

GoF的《设计模式》以及Martin Fowler的《重构》都是经典。而《重构与模式》则是将二者结合起来。通过设计模式来指导重构，而重构的目的就是让代码更加的简单，易于维护和扩展。

写作缘由

  • 过度设计：代码存在设计过度的情况
  • 模式万灵丹：认为设计模式的万能的
  • 设计不足：类比与过度设计，长期设计不足，导致开发节奏“快、慢、更慢”
  • 测试驱动开发和持续重构：敏捷开发中，Kent Beck说开发过程是“红-绿-重构”
  • 重构与模式：模式有助于改进设计，通过重构实现模式或者趋向模式进行重构
  • 演进式设计：将模式放到重构的背景中进行领会

什么是重构

定义：重构是一种对软件内部结构的改善，目的是在不改变软件的可见行为的情况下，使其更易理解，修改成本更低。
重构过程包括去除重复、简化复杂逻辑和澄清模糊的代码。要保证重构的安全性，必须确保所做的修改不会产生任何破坏，这需要进行手工测试或者自动化测试。循序渐进的进行重构有处于防止增加缺陷。

重构的动机：

  • 使新代码的增加更容易
  • 改善既有代码的设计
  • 对代码理解更透彻
  • 提高编程的趣味性

什么是模式

GoF的《设计模式》是在软件开发中总结出来的用于解决不同场景下的软件开发模式。但是不应该陷入模式痴迷，应保证代码的可读性。
应该知道实现模式的方法不止一种，通过重构是为了实现、趋向和去除模式。通常情况下模式不会使代码更加复杂，实现模式有助于去除重复代码、简化逻辑、说明意图和提高灵活性，但是这也取决于人们对模式的熟悉程度。

代码坏味

  • 1.重复代码（Duplicated Code）

    形成Template Method;用Factory Method引入多态创建；链构造函数；用Composite替换一/多之分；提取Composite；通过Adapter统一接口；引入Null Object；

  • 2.过长函数（Long Method）：

    组合方法；将聚集操作搬移到Collecting Parameter；用Command替换条件调度程序；将聚集操作搬移到Visitor；用Strategy替换条件逻辑；

  • 3.条件逻辑太复杂（Conditional Complexity）：

    用Strategy替换条件逻辑；将装饰功能搬移到Decorator;用State替换状态改变条件语句；引入Null Object;

  • 4.基本类型偏执（Primitive Obsession）:

    用类替换类型代码；用State替换状态改变条件语句；用Strategy替换条件逻辑；用Composite替换隐含树；用Interpreter替换隐式语言；将装饰功能搬移到Decorator；用Builder封装Composite。

  • 5.不恰当的暴露（Indecent Exposure）：

    用Factory封装类；

  • 6.解决方案蔓延（Solution Sprawl）：

    将创建知识搬移到Factory；

  • 7.异曲同工的类（Alternative Classes With Different Interfaces）：

    通过Adapter统一接口；

  • 8.冗赘类（Lazy Class）：

    内联Singeton；

  • 9.过大的类（Large Class）：

    用Command替换条件调度程序；用State替换状态改变条件语句；用Interpreter替换隐式语言；

  • 10.分支语句（Switch Statement）：

    用Command替换条件调度程序；将聚集操作搬移到Visitor；

  • 11.组合爆炸（Combinatorial Explosion）：

    用Interpreter替换隐式语言；

  • 12.怪异解决方案（Oddball Solution）：

    通过Adapter统一接口；

创建

用Creation Method替换构造函数

如果类中有多个构造函数，那么客户代码就可能不知道该调用哪一个。这个时候，可以使用能够说明意图的返回对象实例的Creation Method来替换构造函数。
优缺点：
+比构造函数能够更好的表达所创建的实例的种类。
+避免了构造函数的局限，比如2个构造函数的参数数目和类型不能相同。
+更容易发现无用的创建代码。
-创建方式是非标准的：有些是用new初始化，有的是用Creation Method实例化。

将创建知识搬移到Factory

当创建一个对象的知识散布在多个类中，说明出现了创建蔓延的问题。应该将有关的创建知识搬移到一个Factory类中。
优缺点：
+合并创建逻辑和实例化/配置选项。
+将客户代码与创建逻辑解耦。
-如果可以直接实例化，会使设计复杂化。

用Factory封装类

如果在同一个包结构中，有实现了同一接口的多个类。可以把类的构造函数声明为非公共的，并通过Factory来创建它们的实例。
优缺点：
+通过意图导向的CreationMethod简化了不同种类实例的创建。
+通过隐藏不需要公开的类减少了包结构的“概念重量”
+帮助严格执行“面向接口编程，而不是面向实现”这一格言。
-当需要创建新种类的实例时，必须新建/更新Creation Method。
-当客户只获得Factory的二进制代码而无法获得源代码时，对Factory的制定将受到限制。

用Factory Method引入多态创建

一个层次中的类都相似的实现一个方法，只是对象创建的步骤不同。可以调用Factory Method来处理实例化的方法的唯一超类版本。
优缺点：
+减少因创建自定义对象而产生的重复代码
+有效的表达了对象创建发生的位置，以及如何重写对象的创建。
+强制Factory Method使用的类必须实现统一的类型。
-可能会向Factory Method的一些实现者传递不必要的参数。

用Builder封装Composite

构造Composite是重复的、复杂的且容易出错的工作。通过使用Builder处理构造细节来简化构造过程。
优缺点：
+简化了构造Composite的客户代码。
+减少了创建Composite的重复和易出错的本性。
+在客户代码和Composite之间实现了松耦合。
-接口可能不会很清楚的表达其意图。

内联Singleton

绝大多数时候，Singleton都是不需要的。当可以设计或重新设计而避免使用它们的时候，Singleton就是不必要的。可以考虑把Singleton的功能搬移到一个保存并提供对象访问入口的类中，并删除Singleton。
优缺点：
+使对象的协作变得更明显和明确。
+保护了单一的实例，且不要要特殊的代码。
-当在许多层次间传递对象实例比较困难的时候，会使设计变得复杂。

简化

组合方法

一个方法逻辑很难理解的时候，就要考虑进行重构。提高每一步骤的可读性。
优缺点：
+清晰的描述了一个方法所实现的功能以及如何实现。
+把方法分解成命名良好的，处在细节的同一层面的行为模块，以此来简化方法。
-可能会产生过多的小方法。
-可能会使调试变得困难，因为程序的逻辑分散在许多小方法中。

用Strategy替换条件逻辑

当一个方法的条件逻辑太多太复杂的时候，考虑使用Strategy模式来为每个分支创建一个Strategy。
优缺点：
+通过减少或去除条件逻辑使算法变得清晰易懂。
+通过把算法的变体搬移到类层次中简化了类。
+允许在运行时用一种算法替换另一种算法。
-当应用基于继承的解决方案或“简化条件表达式”中的重构更简单时，会增加设计的复杂度。
-增加了算法如何获取或接受上下文类的数据的复杂度。

将装饰功能搬移到Decorator

如果需要对一个功能进行增强，那增强的部分就称为装饰功能了。如果直接改代码那是不好的，考虑使用Decorator模式吧。把这个装饰功能放到装饰器内部。
优缺点：
+把装饰功能从类中搬移去除，从而简化了类。
+有效地把类的核心职责和装饰功能区分开来。
+可以去除几个相关类中重复的装饰逻辑。
-改变了被装饰对象的对象类型。
-会使代码变得更难理解和调适。
-当Decorator组合产生负面影响的时候，会增加设计的复杂度。

用State替换状态改变条件语句

如果控制一个对象状态转换的条件表达式过于复杂，那么就使用State模式吧。
优缺点：
+减少或去除状态改变条件逻辑。
+简化了复杂的状态改变逻辑。
+提供了观察状态改变逻辑的很好的鸟瞰图。
-当状态转换逻辑已经易于理解的时候，会增加设计的复杂度。

用Composite替换隐含树

有一些逻辑用原生表示法隐含的形成了树结构。可以使用Composite来进行重构。
优缺点：
+封装重复的指令，如格式化、添加或删除结点。
+提供了处理相似逻辑增长的一般性方法。
+简化了客户代码的构造职责。
-当构造隐式树更简单的时候，会增加设计的复杂度。

用Command替换条件调度程序

许多系统会收到，发送并处理请求。条件调度程序是一条条条件语句，它用来执行请求的发送和处理。可以使用Command模式来实现。
优缺点：
+提供了用统一方法执行不同行为的简单机制。
+允许在运行时改变所处理的请求，以及如何处理请求。
+仅仅需要很少的代码实现。
-当条件调度程序已经足够的时候，会增加设计的复杂度。

泛化

形成Template Method

借助Template设计模式，将算法的不变部分全部由父类实现，而可变的行为留给子类来实现。去掉所有子类的不变部分，如果仍有共同的部分，则继续重构。
优点与缺点：
+通过把不变行为搬移到超类，去除子类中的重复代码
+简化并有效地表达了一个通用算法的步骤。
+允许子类很容易的定制一个算法
-当为了生成算法、子类必须实现很多方法的时候，会增加设计的复杂度。

提取Composite

在处于同一层次的子类中，如果存在完全重复的方法或者部分重复的方法，就可以考虑将这个方法上移到超类。完全重复的方法，直接提取上移。对于部分重复的方法，可以先提取出重复的部分，然后上移。
优缺点：
+去除重复的类存储逻辑和类处理逻辑。
+能够有效的表达类处理逻辑的可继承性。

用Composite替换一/多之分

这个名字，翻译的貌似有点问题。不知道原文是如何写的。简单说，它处理了以下问题：
如果一个类含有2个几乎一样的方法，唯一的区别就是一个用来处理单一对象，一个用来处理对象的集合。那么这个就称为一/多之分。这个时候，我们可以使用Composite进行替换。
使用Composite扩展出And，Or等条件，简化客户端的处理。
优缺点：
+去除与处理一个或多个对象相关联的重复代码。
+提供了处理一个或多个对象的同一方法。
+支持处理多个对象的更丰富的方法。（如OR表达式）
-可能会在Composite的构造过程中要求类型安全的运行时检查。

用Observer替换硬编码的通知

拒绝使用硬编码的通知，考虑使用Observer模式。
优缺点：
+使主题及其观察者访问松散耦合
+支持一个或多个观察者
-当硬编码的通知已经足够的时候，会增加设计复杂度
-当出现串联通知的时候，会增加代码的复杂度
-当观察者没有从他们的主题中被删除的时候，可能会造成内存泄漏。

通过Adapter统一接口

全部满足以下条件，考虑使用Adapter:

  • 2个类所做的事情相同或者相似，但是具有不同的接口。
  • 如果类共享同一个接口，客户代码会更简单、更直接、更紧凑。
  • 无法轻易改变其中一个类的接口，因为它是第三方类库的一部分，或者它是一个已经被其他客户代码广泛使用的框架的一部分，或者无法获得源代码。

比如slf4j，就是通过各种Adapter实现了各种日志系统的大一统，并提供统一的接口。
优缺点：
+使得客户代码可以通过相同的接口与不同的类交互，从而去除或减少了重复代码。
+使客户代码可以通过公共的接口与多个对象交互，从而简化了客户代码。
+统一了客户代码与不同的类的交互方式。
-当类的接口可以改变的时候，会增加设计的复杂度。

提取Adapter

当一个类适配了多个版本的组件，类库，API或其他实体。这个时候，应该为组件，类库，API或其他实体的每个版本提取一个Adapter。
优缺点：
+隔离了不同版本的组件，类库或API之间的不同之处。
+使类只负责适配代码的一个版本。
+避免频繁地修改代码
-如果某个重要行为在Adapter中不可用的话，那么客户代码将无法执行这一重要行为。

用Interpreter替换隐式语言

在前面“用Composite替换一/多之分”部分，提到了使用Composite的问题。但是使用了Composite后，是需要对Composite进行翻译的。否则是不知道如何查询的。
优缺点：
+比隐式语言更好的支持语言元素的组合。
+不需要新的代码来支持语言元素的新组合。
+允许行为的运行时配置。
-会产生定义语法和修改客户代码的开销。
-如果语言很复杂，则需要很多的编程工作。
-如果语言本身就很简单，则会增加设计的复杂度。

保护

用类替换类型代码

字段的类型（如，String或int）无法保护它免受不正确的赋值和非法的等同性比较。使用类进行替代，从而可以限制赋值和等同性比较。
优缺点：
+更好的避免非法赋值和比较。
-比使用不安全类型要求更多的代码。

用Singleton限制实例化

有时间，遇到创建了一个对象的多个实例，导致内存使用过多和系统性能下降。可以使用单例模式。慎用。
优缺点：
+改进性能。
-从任何地方都可以很容易的访问。在很多情况下，这可能是设计的缺点。
-当对象含有不能共享的状态的时候，本重构就无效了。

引入Null Object

代码中到处都是处理null字段或变量的重复逻辑。而使用Null Object可以进行改善。
优缺点：
+不需要重复的null逻辑就可以避免null错误。
+通过最小化null测试简化了代码。
-当系统不太需要null测试的时候，会增加设计的复杂度。
-如果程序员不知道Null Object的存在，就会产生多余的null测试。
-使维护变得复杂。拥有超类的Null Object必须重写所有新继承到的公共方法。

聚集操作

将聚集操作搬移到Collecting Parameter

有一个很大的方法将信息聚集到一个局部变量中，那么可以把结果聚集到一个Collecting Parameter中，将它传入被提炼出的方法。
优缺点：
+帮助我们把很大的方法转换成更小的，更简单的多个方法。
-使结果代码运行得更快。

将聚集操作搬移到Visitor

如果一个方法需要从不同的类中聚集信息，可以考虑把聚集工作搬移到一个能够访问每个类以便聚集信息的Visitor中。
优缺点：
+调节多个算法，使其适用于不同的对象结构。
+访问相同或不同继承结构中的类。
+调用不同类上的类型特定方法，无需类型转换。
-当可以使用通用接口把互不相同的类变成相似类的时候，会增加代码的复杂度。
-新的可访问类需要新的接受方法，每个Visitor中需要新的访问方法。
-可能会破坏被访问类的封装性。