《重构-改善既有代码的设计》学习笔记(二)

关于《重构-改善既有代码的设计》第一版的学习笔记。本节主要是书中的重构列表也即具体重构方法。因内容较多,仅简单记录名称、解释和一些值得注意的细节以供查阅。

重构列表

重新组织函数

Extract Method (提炼函数)

  • 你有一段代码可以被组织在一起并独立出来
  • 将这段代码放进一个独立函数中,并让函数名称解释该函数的用途
1
2
3
4
5
6
7
8
void printOwing(double amount)
{
printBanner();

// print details
System.out.println("name:" + _name);
System.out.println("amount" + _amount);
}
1
2
3
4
5
6
7
8
9
10
11
void printOwing(double amount)
{
printBanner();
printDetails(amount);
}

void printDetails(double amount)
{
System.out.println("name" + _name);
System.out.println("amount" + amount);
}

注意目标代码中的局部变量。如果需要对局部变量进行再次赋值并使用,提炼出的函数可以使用参数以及返回值。

Inline Method (内联函数)

  • 一个函数的本体和名称同样清楚易懂
  • 在函数调用点插入函数本体,然后移除该函数

与上一条完全相反,这里是去除不必要的间接性。另一种情况是需要整理大量不甚合理的小函数时,先全部内联到一个大函数中,再重新进行提炼。

Inline Temp (内联临时变量)

  • 你有一个临时变量,只被一个简单表达式赋值一次,而妨碍了其他重构手法
  • 将所有对该变量的引用动作,替换为对它赋值的那个表达式自身

多半作为下一条的一部分使用,通常不会有什么危害,但是如果妨碍了其他重构思路,就可以将其内联化。使用时可以通过将这个临时变量设置为final以检查其是否只被赋值一次。

Replace Temp with Query (以查询取代临时变量)

  • 你的程序以一个临时变量保存某一表达式的运算结果
  • 将这个表达式提炼到一个独立函数中。将这个临时变量的所有引用点替换为对新函数的调用。此后,新函数就可以被其他函数使用。
1
2
3
4
5
double basePrice = _quantity * _itemPrice;
if (basePrice > 1000)
return basePrice * 0.95;
else
return basePrice * 0.95
1
2
3
4
5
6
7
8
9
if (basePrice() > 1000)
return basePrice() * 0.95;
else
return basePrice() * 0.95
...
double basePrice()
{
return _quantity * _itemPrice;
}

也就是让一个函数中的表达式计算可以被其他函数使用。通常是 Extra Method 前的步骤。运用此手法可能会产生性能问题,但是通常可以忽略不计,或是可以在性能优化阶段解决。

Introduce Explaining Variable (引入解释性变量)

  • 你有一个复杂的表达式
  • 将该复杂表达式(或其中一部分)的结果放进一个临时变量,以此变量名称来解释表达式用途。

也是和上一条相反。当表达式非常复杂难以阅读时使用。当然,也可以使用 Extract Method。何时使用二者可以根据具体工作量来判断。

Split Temporary Variable (分解临时变量)

  • 你的程序有某个临时变量被赋值超过一次,它既不是循环变量,也不被用于收集计算结果。
  • 针对每次赋值,创造一个独立,对应的临时变量

除了循环变量和结果收集变量。临时变量大多不应被多次赋值。也即临时变量不应承担多个责任。

Remove Assignments to Parameters (移除对参数的赋值)

  • 代码对一个参数进行赋值
  • 以一个临时变量取代该参数的位置

以下为一段java代码(采用按值传递)

1
2
3
4
5
void aMethod(Object foo)
{
foo.modifyInSomeWay; //可
foo = anotherObject; //不可
}

这导致混用按值传递和按引用传递,降低代码清晰度。

Replace Method with Method Object (以函数对象取代函数)

  • 你有一个大型函数,其中对局部变量的引用使你无法采用 Extract Method
  • 将这个函数放进一个单独对象中,如此一来局部对象就成了对象内的字段。然后你可以在同一个对象中将这个大型函数分解为多个小型函数。

Substitute Algorithm (替换算法)

  • 你想要将某个算法替换为另一个更清晰的算法
  • 将函数本体替换为另一个算法

在对象之间搬移特性

Move Method (搬移函数)

  • 你的程序中,有个函数与其所驻类之外的另一个类进行更多交流:调用后者,或被后者调用
  • 在该函数最常引用的类中建立一个有类似行为的新函数。将旧函数变成一个单纯的委托函数,或是将旧函数完全移除。

Move Field (搬移字段)

  • 你的程序中,某个字段被其所驻类之外的另一个类更多地用到
  • 在目标类新建一个字段,修改源字段的所有用户,令它们改用新字段

Extract Class (提炼类)

  • 某个类做了应该由两个类做的事
  • 建立一个新类,将相关的字段和函数从旧类搬移到新类

信号之一是类的子类化方式出现问题,如果子类化只影响了类的部分特性或类的不同特性需要以不同方式来子类化,这意味着需要分解原来的类。

Inline Class (将类内联化)

  • 某个类没有做太多事情
  • 将这个类的所有特性搬移到另一个类中,然后移除原类

看起来我需要被内联
这与上一条相反,当类不再有单独存在的理由时,应当将该类移入它的最频繁用户中。

Hide Delegate (隐藏“委托关系”)

  • 客户通过一个委托类来调用另一个对象
  • 在服务类上建立客户所需的所有函数,用以隐藏委托关系

可以在服务器对象上放置一个简单的委托函数,将委托关系隐藏起来,从而去除一些依赖关系。这样即使发生委托关系上的方法,变化也将被限制在服务对象中,不会波及客户。

Remove Middle Man (中间人)

  • 某个类做了过多的简单委托动作
  • 让客户直接调用受托类

与上一条相反,随着受托类的特性和功能越来越多,服务类会完全变成“中间人”,此时你就应该让客户直接调用受托类。使用这一条和上一条可以保证隐藏的程度是合适。

Introduce Foreign Method (引入外加函数)

  • 你需要为提供服务的类增加一个函数,但你无法修改这个类
  • 在客户类中建立一个函数,并以第一参数形式传入一个服务类实例
1
Date newStart = new Date(previousEnd.getYear(),previousEnd.getMonth(),previousEnd.getDate() + 1);
1
Date newStart = nextDay(previousEnd)

正在使用一个类时,如果你需要一项服务而类无法供应,此时如果你能修改源码,可以自行添加一个新函数,如果不能,就要在客户端编码,补足所需的函数。明确信号是这个函数本应在服务类中实现,如果有可能,这些函数仍然应该放回到服务类。

Introduce Local Extension (引入本地扩展)

  • 你需要为服务类提供一些额外函数,但你无法修改这个类
  • 建立一个新类,使它包含这些额外函数。让这个扩展品成为源类的子类或包装类。

和上一条的情况类似,如果你需要少数函数,你可以使用上一条的方法,而如果你需要加入多个函数,就可以使用本地扩展。例如子类化和包装。作者通常采取子类。

重新组织数据

Self Encapsulate Field (自封装字段)

  • 你直接访问一个字段,但与字段之间的耦合关系逐渐变得笨拙
  • 为这个字段建立取值/设值函数,并且只以这些函数来访问字段

如果一个类中有private字段,是否可以自由访问,还是应该使用访问函数间接访问,有两个说法。
间接访问变量的函数的好处是,子类可以通过覆写一个函数而改变获取数据的途径;它还支持更灵活的数据管理方式,例如延迟初始化。
直接访问变量的好处则是,代码比较容易阅读。
如果你想要访问超类中的一个字段,却又想在子类中将对这个变量的访问改为一个计算后的值,就应该使用这一方法。

Replace Data Value with Object (以对象取代数据值)

  • 你有一个数据项,需要与其他数据和行为一起使用才有意义
  • 将数据项变成对象

开发初期,对于电话号码一类的数据可能会出现,早期使用字符串表示,但后来发现需要抽取区号等行为。如果这样的数据项只有一两个,你可以把相关函数放进数据项所属的对象里;但是 Duplicate Code 和 Feature Envy bad smell就可能会出现,这时就需要把数据值变成对象。

Change Value to Reference (将值对象改为引用对象)

  • 你从一个类衍生出许多彼此相等的实例,希望将它们替换为同一个对象

Change Reference to Value (将引用对象改为值对象)

  • 你有一个引用对象,很小且不可变,而且不易管理

和上一条相反。如果引用对象开始难以使用,就可能需要改为值对象。
值对象的重要特性是不可变(immutable)的。例如如果用Money类表示钱的概念,那Money类通常是一个不可变的值对象,这不意味着你的薪资不能改变,而是说改变薪资需要使用新的Money类对象代替而非修改现有的Money类。

Replace Array with Object (以对象取代数组)

  • 你有一个数组,其中的元素各自代表不同的东西
  • 以对象替换数组。对于数组中的每个元素,以一个字段来表示

Duplicate Observed Data (复制 “被监视数据”)

  • 你有一些领域置身于GUI控件中,而领域函数需要访问这些数据
  • 将该数据复制到一个领域对象中。建立一个Observer模式,用以同步领域对象和GUI对象内的重复数据

Change Unidirectional Association to Bidirectional (将单向关联改为双向关联)

  • 两个类都需要使用对方特性,但其间只有一条单向连接
  • 添加一个反向指针,并使修改函数能够同时更新两条连接

Change Bidirectional Association to Unidirectional (将双向关联改为单向关联)

  • 两个类之间有双向关联,但其中一个类如今不再需要另一个类的特性
  • 去除不必要的关联

Replace Magic Number with Symbolic Constant (以字面常量取代魔法数)

  • 你有一个字面数值,带有特别含义
  • 创造一个常量,根据其意义为它命名,并将上述的字面数值替换为这个常量

Encapsulated Field (封装字段)

  • 你的类中存在一个public字段
  • 将它声明为private,并提供相应的访问函数

Encapsulate Collection (封装集合)

  • 有个函数返回一个集合
  • 让这个函数返回该集合的一个只读副本,并在这个类中提供添加/移除集合元素的函数

Replace Record with Data Class (以数据类取代记录)

  • 你需要面对传统编程环境中的记录结构
  • 为该记录创建一个“哑”数据对象

创建一个接口类以处理外来的记录型结构(所以记录式结构是什么)

Replace Type Code with Class (以类取代类型码)

  • 类之中有一个数值类型码,但它并不影响类的行为
  • 以一个新的类替换该数值类型码

Replace Type Code with Subclasses (以子类取代类型码)

  • 你有一个不可变的类型码,它会影响类的行为
  • 以子类取代这个类型码

Replace Type Code with State/Strategy (以 State/Strategy 取代类型码)

  • 你有一个类型码,它会影响类的行为,但你无法通过继承手法消除它
  • 以状态对象取代类型码

如果类型码的值在对象生命周期中发生变化或其他原因使得宿主类不能被继承,可以使用本重构

Replace Subclass with Fields (以字段取代子类)

  • 你的各个子类的唯一差别只在“返回常量数据”的函数上
  • 修改这个函数,使他们返回超类中的某个(新增)字段,然后销毁子类

简化条件表达式

Decompose Conditional (分解条件表达式)

  • 你有一个复杂的条件 (if - then - else)
  • 从 if,then,else 三个段落中分别提炼出独立函数

Consolidate Conditional Expression (合并条件表达式)

  • 你有一系列条件测试,都得到相同结果
  • 将这些测试合并为一个条件表达式,并将这个条件式提炼成为一个独立函数
    1
    2
    3
    4
    5
    6
    7
    double disabilityAmount()
    {
    if (_seniority < 2) return 0;
    if (_monthsDisabled < 12) return 0;
    if (_isPartTime) return 0;
    //...
    }
1
2
3
4
5
double disabilityAmount()
{
if (isNotEligableForDisability()) return 0;
//...
}

Consolidate Duplicate Conditional Fragments (合并重复的条件片段)

  • 在条件表达式的每个分支上有着相同的一段代码
  • 将这段重复代码搬移到条件表达式之外

Remove Control Flag (移除控制标记)

  • 在一系列布尔表达式中,某个变量带有”控制标记”(control flag)的作用
  • 以 break 语句或 return 语句取代控制标记
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    void checkSecurity(String people)
    {
    boolean found = false;
    for (int i = 0; i < people.length; i++)
    {
    if (!found)
    {
    if (people(i).equals("Don"))
    {
    sendAlert();
    found = true;
    }
    if (people(i).equals("John"))
    {
    sendAlert();
    found = true;
    }
    }
    }
    }
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
void checkSecurity(String[] people)
{
for (int i = 0; i < people.length; i++)
{
if (people(i).equals("Don"))
{
sendAlert();
break;
}
if (people(i).equals("John"))
{
sendAlert();
break;
}
}
}

这两段书中示例的代码在同时满足两个条件时的输出是不一致的,不过对于示例中检测两个嫌疑人名字的情形应该不会出现这种情况。
如果这里的found同时用于输出结果,可以使用 return 重构

Replace Nested Conditional with Guard Clauses (以卫语句取代嵌套表达式)

  • 函数中的条件逻辑使人难以看清正常的执行路径
  • 使用卫语句表现所有特殊情况
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    double getPayAmount()
    {
    double result;
    if (_isDead)
    {
    result = deadAmount();
    }
    else
    {
    if (_isSeparted)
    {
    result = separatedAmount();
    }
    else
    {
    if (_isRetired) result = retiredAmount();
    else result = normalPayAmount();
    }
    }
    }
    1
    2
    3
    4
    5
    6
    7
    double getPayAmount()
    {
    if (_isDead) return deadAmount();
    if (_isSeparated) return separatedAmount();
    if (_isRetired) return retiredAmount();
    return normalPayAmount();
    }

条件表达式通常有两种表现形式,一种是所有分支都是正常行为,另一种是只有一种是正常行为,其他都是特殊情况。
对于第一种就应该使用if-else语句,而对于第二种就应当使用卫语句。卫语句通常从函数中返回或抛异常。

Replace Conditional with Polymorphism (以多态取代条件表达式)

  • 你手上有个条件表达式,它根据对象类型的不同而选择不同的行为
  • 将这个条件表达式的每个分支放进一个子类内的覆写函数中,然后将原始函数声明为抽象函数

Introduce Null Object (引入Null对象)

  • 你需要再三检查某对象是否为null
  • 将null值替换为null对象

也即引入 Null Object 设计模式。
例如对于 Customer 对象和持有的 getPlan 方法,可以建立空对象类 Null Customer 继承 Customer 类,并用空对象对应行为替换 Null Customer 类的 getPlan 方法。
实际使用时,注意在源类和子类中加入 isNull() 函数,前者返回 false ,后者的 isNull() 返回true。也可以建立 nullable 接口将 isNull() 放在其中。之后所有将源对象与 null 比较的地方就可以调用 isNull() 函数。

Introduce Assertion (引入断言)

  • 某一段代码需要对程序状态做出某种假设
  • 以断言明确表现这种假设
    1
    2
    3
    4
    5
    6
    7
    double getExpenseLimit()
    {
    // should have either expense limit or a primary project
    return (_expenseLimit != NULL_EXPENSE) ?
    _expenseLimit:
    _primaryProject.getMemberExpenseLimit()
    }
    1
    2
    3
    4
    5
    6
    7
    double getExpenseLimit()
    {
    Assert.isTure(_expenseLimit != NULL_EXPENSE || _primaryProject != null)
    return (_expenseLimit != NULL_EXPENSE) ?
    _expenseLimit:
    _primaryProject.getMemberExpenseLimit()
    }

简化函数调用

Rename Method (函数改名)

  • 函数的名称未能揭示函数的用途
  • 修改函数名称

作者提倡的好方法是先考虑给这个函数写上一句怎样的注释,再想办法将注释变成函数名称。

Add Parameter (添加参数)

  • 某个函数需要从调用端得到更多信息
  • 为此函数添加一个对象参数,让该对象带进函数所需信息

Remove Parameter (移除参数)

  • 函数本体不再需要某个参数
  • 将该参数去除

Separate Query from Modifier (将查询函数和修改函数分离)

  • 某个函数既返回对象状态值,又修改对象状态
  • 建立两个不同的函数,其中一个负责查询,另一个负责修改

也即分离 getter setter

Parameterize Method (令函数携带参数)

  • 若干函数做了类似的工作,但在函数本体中却包括了不同的值
  • 建立单一函数,以参数表达那些不同的值

Replace Parameter with Explicit Methods (以明确函数取代参数)

  • 你有一个函数,其中完全取决于参数值而采取不同行为
  • 针对该参数的每一个可能值,建立一个独立函数

Preserve Whole Object (保持对象完整)

  • 你从某个对象中取出若干值,将它们作为某一次函数调用时的参数
  • 改为传递整个对象

Replace Parameter with Methods (以函数取代参数)

  • 对象调用某个函数,并将所得结果作为参数,传递给另一个函数。而接受该参数的函数本身也能够调用前一个函数
  • 让参数接受者去除该项参数,并直接调用前一个函数
1
2
3
int basePrice = _quantity * _itemPrice;
discountLevel = getDiscountLevel();
double finalPrice = discountedPrice(basePrice,discountLevel);
1
2
int basePrice = _quantity * _itemPrice;
double finalPrice = discountedPrice(basePrice);

Introduce Parameter Object (引入参数对象)

  • 某些参数总是很自然地同时出现
  • 以一个对象取代这些参数

Remove Setting Method (移除设值函数)

  • 类中的某个字段应该在对象创建时被设值,然后就不再改变
  • 去掉该字段的所有设值函数

Hide Method (隐藏函数)

  • 有一个函数,从来没有被其他任何类用到
  • 将这个函数修改为 private

Replace Constructor with Factory Method (以工厂函数取代构造函数)

  • 你希望在创建对象时不仅仅是做简单的建构动作
  • 将构造函数替换为工厂函数

最显而易见的用途是在派生子类的过程中以工厂函数取代类型码,或者构造函数的功能不能满足你的需要,也可以用工厂函数替代它。

Encapsulate Downcast (封装向下转型)

  • 某个函数返回的对象,需要由函数调用者执行向下转型(downcast)
  • 将向下转型动作移到函数上
1
2
3
4
Object lastReading()
{
return readings.lastElement();
}
1
2
3
4
Object lastReading()
{
return (Reading) reading.lastElment();
}

Replace Error Code with Exception (以异常取代错误码)

  • 某个函数返回一个特定的代码,用以表示某种错误情况
  • 改用异常

Replace Exception with Test (以测试取代异常)

  • 面对一个调用者可以预先检查的条件,你抛出了一个异常
  • 修改调用者,使它在调用函数之前先做检查

处理概括关系

Pull Up Field (字段上移)

  • 两个子类拥有相同的字段
  • 将该字段移至超类

Pull Up Method (函数上移)

  • 有些函数,在各个子类中产生完全相同的结果
  • 将该函数移至超类

Pull Up Constructor Body (构造函数本体上移)

  • 你在各个子类中拥有一些构造函数,它们的本体几乎完全一致
  • 在超类中新建一个构造函数,并在子类构造函数中调用它

Push Down Method (函数下移)

  • 超类中的某个函数只与部分(而非全部)子类有关
  • 将这个函数移到相关的那些子类去

Push Down Field (字段下移)

  • 超类中的某个字段只被部分(而非全部)子类用到
  • 将这个字段移到需要它的那些子类去

Extract Superclass (提炼超类)

  • 两个类有相似特性
  • 为这两个类建立一个超类,将相同特性移至超类

Extract Interface (提炼接口)

  • 若干客户使用类接口中的同一子类,或者两个类的接口有部分相同
  • 将相同的子集提炼到一个独立接口中

Collapse Hierarchy (折叠继承体系)

  • 超类和子类之间无太大区别
  • 将它们合为一体

Form TemPlate Method (塑造模版函数)

  • 你有一些子类,其中相应的某些函数以相同顺序执行类似的操作,但各个操作的细节上有所不同
  • 将这些操作分别放进独立函数中,并保持它们都有相同的签名,于是原函数也就变得相同了。然后将原函数上移至超类

Replace Inheritance with Delegation (以委托取代继承)

  • 某个子类只使用超类接口中的一部分,或是根本不需要继承而来的错误
  • 在子类中新建一个字段用以保存超类;调查子类函数,令它改而委托超类;然后去掉两者之间的继承关系

Replace Delegation with Inheritance (以继承取代委托)

  • 你在两个类之间使用委托关系,并经常为整个接口编写许多极简单的委托函数
  • 让委托类继承受托类

大型重构

理论上这一章配个图比较合适,不过我的书有水印不想截图,又懒得画类图,所以没有图

Tease Apart Inheritance (梳理并分解继承体系)

  • 某个继承体系同时承担两项责任
  • 建立两个继承体系,并通过委托让其中一个可以调用另一个

Convert Procedural Design to Objects (将过程化设计转化为对象设计)

  • 你手上有一些传统过程化风格的代码
  • 将数据记录变成对象,将大块的行为分成小块,并将行为移入相关对象之中

Separate Domain from Presentation (将领域和表述/显示分离)

  • 某些GUI类之中包含了领域逻辑
  • 将领域逻辑分离出来,为它们建立独立的领域类

Extract Hierarchy (提炼继承体系)

  • 你有某个类做了太多工作,其中一部分工作是以大量条件表达式完成的
  • 建立继承体系,以一个子类表述一种特殊情况

重构,复用与现实

大约是一些重构在实际使用时的注意事项,比较碎而且涉及一些和甲方、上司的交涉之类的现实情况,目前对这一方面没什么理解,所以不整理了。必然不是因为我懒