📦 本文已归档到：「blog」

翻译自：https://sourcemaking.com/refactoring/smells/change-preventers

变革的障碍(Change Preventers)这组坏味道意味着：当你需要改变一处代码时，却发现不得不改变其他的地方。这使得程序开发变得复杂、代价高昂。

发散式变化

发散式变化(Divergent Change) 类似于 霰弹式修改(Shotgun Surgery) ，但实际上完全不同。发散式变化(Divergent Change) 是指一个类受多种变化的影响。霰弹式修改(Shotgun Surgery) 是指多种变化引发多个类相应的修改。

特征

你发现你想要修改一个函数，却必须要同时修改许多不相关的函数。例如，当你想要添加一个新的产品类型时，你需要同步修改对产品进行查找、显示、排序的函数。

问题原因

通常，这种发散式修改是由于编程结构不合理或者“复制-粘贴式编程”。

解决办法

• 运用 提炼类(Extract Class) 拆分类的行为。

收益

• 提高代码组织结构
• 减少重复代码

重构方法说明

提炼类(Extract Class)

问题

某个类做了不止一件事。

解决

建立一个新类，将相关的字段和函数从旧类搬移到新类。

平行继承体系

平行继承体系(Parallel Inheritance Hierarchies) 其实是 霰弹式修改(Shotgun Surgery) 的特殊情况。

特征

每当你为某个类添加一个子类，必须同时为另一个类相应添加一个子类。这种情况的典型特征是：某个继承体系的类名前缀或类名后缀完全相同。

问题原因

起初的继承体系很小，随着不断添加新类，继承体系越来越大，也越来越难修改。

解决方法

• 一般策略是：让一个继承体系的实例引用另一个继承体系的实例。如果再接再厉运用 搬移函数(Move Method) 和 搬移字段(Move Field)，就可以消除引用端的继承体系。

收益

• 更好的代码组织
• 减少重复代码

何时忽略

• 有时具有并行类层次结构只是一种为了避免程序体系结构更混乱的方法。如果你发现尝试消除平行继承体系导致代码更加丑陋，那么你应该回滚你的修改。

重构方法说明

搬移函数(Move Method)

问题

你的程序中，有个函数与其所驻类之外的另一个类进行更多交流：调用后者，或被后者调用。

解决

在该函数最常引用的类中建立一个有着类似行为的新函数。将旧函数变成一个单纯的委托函数，或是旧函数完全移除。

搬移字段(Move Field)

问题

在你的程序中，某个字段被其所驻类之外的另一个类更多地用到。

解决

在目标类新建一个字段，修改源字段的所有用户，令他们改用新字段。

霰弹式修改

霰弹式修改(Shotgun Surgery) 类似于 发散式变化(Divergent Change) ，但实际上完全不同。发散式变化(Divergent Change) 是指一个类受多种变化的影响。霰弹式修改(Shotgun Surgery) 是指多种变化引发多个类相应的修改。

特征

任何修改都需要在许多不同类上做小幅度修改。

问题原因

一个单一的职责被拆分成大量的类。

解决方法

• 运用搬移函数(Move Method) 和 搬移字段(Move Field) 来搬移不同类中相同的行为到一个独立类中。如果没有适合存放搬移函数或字段的类，就创建一个新类。
• 通常，可以运用 将类内联化(Inline Class) 将一些列相关行为放进同一个类。

收益

• 更好的代码组织
• 减少重复代码
• 更易维护

重构方法说明

搬移函数(Move Method)

问题

你的程序中，有个函数与其所驻类之外的另一个类进行更多交流：调用后者，或被后者调用。

解决

在该函数最常引用的类中建立一个有着类似行为的新函数。将旧函数变成一个单纯的委托函数，或是旧函数完全移除。

搬移字段(Move Field)

问题

在你的程序中，某个字段被其所驻类之外的另一个类更多地用到。

解决

在目标类新建一个字段，修改源字段的所有用户，令他们改用新字段。

将类内联化(Inline Class)

问题

某个类没有做太多事情。

解决

将这个类的所有特性搬移到另一个类中，然后移除原类。

扩展阅读

• 代码的坏味道和重构
• 代码坏味道之代码臃肿
• 代码坏味道之滥用面向对象
• 代码坏味道之变革的障碍
• 代码坏味道之非必要的
• 代码坏味道之耦合

参考资料

• 重构——改善既有代码的设计 - by Martin Fowler
• https://sourcemaking.com/refactoring

📦 本文已归档到：「blog」

翻译自：https://sourcemaking.com/refactoring/smells/oo-abusers

滥用面向对象(Object-Orientation Abusers)这组坏味道意味着：代码部分或完全地违背了面向对象编程原则。

Switch 声明

Switch 声明(Switch Statements)

你有一个复杂的 switch 语句或 if 序列语句。

问题原因

面向对象程序的一个最明显特征就是：少用 switch 和 case 语句。从本质上说，switch 语句的问题在于重复（if 序列也同样如此）。你常会发现 switch 语句散布于不同地点。如果要为它添加一个新的 case 子句，就必须找到所有 switch 语句并修改它们。面向对象中的多态概念可为此带来优雅的解决办法。

大多数时候，一看到 switch 语句，就应该考虑以多态来替换它。

解决方法

• 问题是多态该出现在哪？switch 语句常常根据类型码进行选择，你要的是“与该类型码相关的函数或类”，所以应该运用 提炼函数(Extract Method) 将 switch 语句提炼到一个独立函数中，再以 搬移函数(Move Method) 将它搬移到需要多态性的那个类里。
• 如果你的 switch 是基于类型码来识别分支，这时可以运用 以子类取代类型码(Replace Type Code with Subclass) 或 以状态/策略模式取代类型码(Replace Type Code with State/Strategy) 。
• 一旦完成这样的继承结构后，就可以运用 以多态取代条件表达式(Replace Conditional with Polymorphism) 了。
• 如果条件分支并不多并且它们使用不同参数调用相同的函数，多态就没必要了。在这种情况下，你可以运用 以明确函数取代参数(Replace Parameter with Explicit Methods) 。
• 如果你的选择条件之一是 null，可以运用 引入 Null 对象(Introduce Null Object) 。

收益

• 提升代码组织性。

何时忽略

• 如果一个 switch 操作只是执行简单的行为，就没有重构的必要了。
• switch 常被工厂设计模式族（工厂方法模式(Factory Method)和抽象工厂模式(Abstract Factory)）所使用，这种情况下也没必要重构。

重构方法说明

提炼函数(Extract Method)

问题

你有一段代码可以组织在一起。

1
2
3
4
5
6
7

void printOwing() {
  printBanner();

  //print details
  System.out.println("name: " + name);
  System.out.println("amount: " + getOutstanding());
}

解决

移动这段代码到一个新的函数中，使用函数的调用来替代老代码。

1
2
3
4
5
6
7
8
9

void printOwing() {
  printBanner();
  printDetails(getOutstanding());
}

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

搬移函数(Move Method)

问题

你的程序中，有个函数与其所驻类之外的另一个类进行更多交流：调用后者，或被后者调用。

解决

在该函数最常引用的类中建立一个有着类似行为的新函数。将旧函数变成一个单纯的委托函数，或是旧函数完全移除。

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

问题

你有一个不可变的类型码，它会影响类的行为。

解决

以子类取代这个类型码。

以状态/策略模式取代类型码(Replace Type Code with State/Strategy)

问题

你有一个类型码，它会影响类的行为，但你无法通过继承消除它。

解决

以状态对象取代类型码。

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

问题

你手上有个条件表达式，它根据对象类型的不同而选择不同的行为。

1
2
3
4
5
6
7
8
9
10
11
12
13
14

class Bird {
  //...
  double getSpeed() {
    switch (type) {
      case EUROPEAN:
        return getBaseSpeed();
      case AFRICAN:
        return getBaseSpeed() - getLoadFactor() * numberOfCoconuts;
      case NORWEGIAN_BLUE:
        return (isNailed) ? 0 : getBaseSpeed(voltage);
    }
    throw new RuntimeException("Should be unreachable");
  }
}

解决

将这个条件表达式的每个分支放进一个子类内的覆写函数中，然后将原始函数声明为抽象函数。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

abstract class Bird {
  //...
  abstract double getSpeed();
}

class European extends Bird {
  double getSpeed() {
    return getBaseSpeed();
  }
}
class African extends Bird {
  double getSpeed() {
    return getBaseSpeed() - getLoadFactor() * numberOfCoconuts;
  }
}
class NorwegianBlue extends Bird {
  double getSpeed() {
    return (isNailed) ? 0 : getBaseSpeed(voltage);
  }
}

// Somewhere in client code
speed = bird.getSpeed();

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

问题

你有一个函数，其中完全取决于参数值而采取不同的行为。

1
2
3
4
5
6
7
8
9
10
11

void setValue(String name, int value) {
  if (name.equals("height")) {
    height = value;
    return;
  }
  if (name.equals("width")) {
    width = value;
    return;
  }
  Assert.shouldNeverReachHere();
}

解决

针对该参数的每一个可能值，建立一个独立函数。

1
2
3
4
5
6

void setHeight(int arg) {
  height = arg;
}
void setWidth(int arg) {
  width = arg;
}

引入 Null 对象(Introduce Null Object)

问题

你需要再三检查某对象是否为 null。

1
2
3
4
5
6

if (customer == null) {
  plan = BillingPlan.basic();
}
else {
  plan = customer.getPlan();
}

解决

将 null 值替换为 null 对象。

1
2
3
4
5
6
7
8
9
10
11
12

class NullCustomer extends Customer {
  Plan getPlan() {
    return new NullPlan();
  }
  // Some other NULL functionality.
}

// Replace null values with Null-object.
customer = (order.customer != null) ? order.customer : new NullCustomer();

// Use Null-object as if it's normal subclass.
plan = customer.getPlan();

临时字段

临时字段(Temporary Field)的值只在特定环境下有意义，离开这个环境，它们就什么也不是了。

问题原因

有时你会看到这样的对象：其内某个实例变量仅为某种特定情况而设。这样的代码让人不易理解，因为你通常认为对象在所有时候都需要它的所有变量。在变量未被使用的情况下猜测当初设置目的，会让你发疯。
通常，临时字段是在某一算法需要大量输入时而创建。因此，为了避免函数有过多参数，程序员决定在类中创建这些数据的临时字段。这些临时字段仅仅在算法中使用，其他时候却毫无用处。
这种代码不好理解。你期望查看对象字段的数据，但是出于某种原因，它们总是为空。

解决方法

• 可以通过 提炼类(Extract Class) 将临时字段和操作它们的所有代码提炼到一个单独的类中。此外，你可以运用 以函数对象取代函数(Replace Method with Method Object) 来实现同样的目的。
• 引入 Null 对象(Introduce Null Object) 在“变量不合法”的情况下创建一个 null 对象，从而避免写出条件表达式。

收益

• 更好的代码清晰度和组织性。

重构方法说明

提炼类(Extract Class)

问题

某个类做了不止一件事。

解决

建立一个新类，将相关的字段和函数从旧类搬移到新类。

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

问题

你有一个过长函数，它的局部变量交织在一起，以致于你无法应用提炼函数(Extract Method) 。

1
2
3
4
5
6
7
8
9
10

class Order {
  //...
  public double price() {
    double primaryBasePrice;
    double secondaryBasePrice;
    double tertiaryBasePrice;
    // long computation.
    //...
  }
}

解决

将函数移到一个独立的类中，使得局部变量成了这个类的字段。然后，你可以将函数分割成这个类中的多个函数。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

class Order {
  //...
  public double price() {
    return new PriceCalculator(this).compute();
  }
}

class PriceCalculator {
  private double primaryBasePrice;
  private double secondaryBasePrice;
  private double tertiaryBasePrice;

  public PriceCalculator(Order order) {
    // copy relevant information from order object.
    //...
  }

  public double compute() {
    // long computation.
    //...
  }
}

引入 Null 对象(Introduce Null Object)

问题

你需要再三检查某对象是否为 null。

1
2
3
4
5
6

if (customer == null) {
  plan = BillingPlan.basic();
}
else {
  plan = customer.getPlan();
}

解决

将 null 值替换为 null 对象。

1
2
3
4
5
6
7
8
9
10
11
12

class NullCustomer extends Customer {
  Plan getPlan() {
    return new NullPlan();
  }
  // Some other NULL functionality.
}

// Replace null values with Null-object.
customer = (order.customer != null) ? order.customer : new NullCustomer();

// Use Null-object as if it's normal subclass.
plan = customer.getPlan();

异曲同工的类

异曲同工的类(Alternative Classes with Different Interfaces)

两个类中有着不同的函数，却在做着同一件事。

问题原因

这种情况往往是因为：创建这个类的程序员并不知道已经有实现这个功能的类存在了。

解决方法

• 如果两个函数做同一件事，却有着不同的签名，请运用 函数改名(Rename Method) 根据它们的用途重新命名。
• 运用 搬移函数(Move Method) 、 添加参数(Add Parameter) 和 令函数携带参数(Parameterize Method) 来使得方法的名称和实现一致。
• 如果两个类仅有部分功能是重复的，尝试运用 提炼超类(Extract Superclass) 。这种情况下，已存在的类就成了超类。
• 当最终选择并运用某种方法来重构后，也许你就能删除其中一个类了。

收益

• 消除了不必要的重复代码，为代码瘦身了。
• 代码更易读（不再需要猜测为什么要有两个功能相同的类）。

何时忽略

• 有时合并类是不可能的，或者是如此困难以至于没有意义。例如：两个功能相似的类存在于不同的 lib 库中。

重构方法说明

函数改名(Rename Method)

问题

函数的名称未能恰当的揭示函数的用途。

1
2
3

class Person {
  public String getsnm();
}

解决

修改函数名。

1
2
3

class Person {
  public String getSecondName();
}

搬移函数(Move Method)

问题

你的程序中，有个函数与其所驻类之外的另一个类进行更多交流：调用后者，或被后者调用。

解决

在该函数最常引用的类中建立一个有着类似行为的新函数。将旧函数变成一个单纯的委托函数，或是旧函数完全移除。

添加参数(Add Parameter)

问题
某个函数需要从调用端得到更多信息。

1
2
3

class Customer {
  public Contact getContact();
}

解决
为此函数添加一个对象函数，让改对象带进函数所需信息。

1
2
3

class Customer {
  public Contact getContact(Date date);
}

令函数携带参数(Parameterize Method)

问题

若干函数做了类似的工作，但在函数本体中却包含了不同的值。

建立单一函数，以参数表达哪些不同的值。

提炼超类(Extract Superclass)

问题

两个类有相似特性。

解决

为这两个类建立一个超类，将相同特性移至超类。

被拒绝的馈赠

被拒绝的馈赠(Refused Bequest)

子类仅仅使用父类中的部分方法和属性。其他来自父类的馈赠成为了累赘。

问题原因

有些人仅仅是想重用超类中的部分代码而创建了子类。但实际上超类和子类完全不同。

解决方法

• 如果继承没有意义并且子类和父类之间确实没有共同点，可以运用 以委托取代继承(Replace Inheritance with Delegation) 消除继承。
• 如果继承是适当的，则去除子类中不需要的字段和方法。运用 提炼超类(Extract Superclass) 将所有超类中对于子类有用的字段和函数提取出来，置入一个新的超类中，然后让两个类都继承自它。

收益

• 提高代码的清晰度和组织性。

重构方法说明

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

问题

某个子类只使用超类接口中的一部分，或是根本不需要继承而来的数据。

解决

1. 在子类中新建一个字段用以保存超类；
2. 调整子类函数，令它改而委托超类；
3. 然后去掉两者之间的继承关系。

提炼超类(Extract Superclass)

问题

两个类有相似特性。

解决

为这两个类建立一个超类，将相同特性移至超类。

扩展阅读

• 代码的坏味道和重构
• 代码坏味道之代码臃肿
• 代码坏味道之滥用面向对象
• 代码坏味道之变革的障碍
• 代码坏味道之非必要的
• 代码坏味道之耦合

参考资料

• 重构——改善既有代码的设计 - by Martin Fowler
• https://sourcemaking.com/refactoring

📦 本文已归档到：「blog」

翻译自：https://sourcemaking.com/refactoring/smells/couplers

耦合(Couplers)这组坏味道意味着：不同类之间过度耦合。

不完美的库类

不完美的库类(Incomplete Library Class)

当一个类库已经不能满足实际需要时，你就不得不改变这个库（如果这个库是只读的，那就没辙了）。

问题原因

许多编程技术都建立在库类的基础上。库类的作者没用未卜先知的能力，不能因此责怪他们。麻烦的是库往往构造的不够好，而且往往不可能让我们修改其中的类以满足我们的需要。

解决方法

• 如果你只想修改类库的一两个函数，可以运用 引入外加函数(Introduce Foreign Method)；
• 如果想要添加一大堆额外行为，就得运用 引入本地扩展(Introduce Local Extension) 。

收益

• 减少代码重复（你不用一言不合就自己动手实现一个库的全部功能，代价太高）

何时忽略

• 如果扩展库会带来额外的工作量。

重构方法说明

引入外加函数(Introduce Foreign Method)

问题

你需要为提供服务的类增加一个函数，但你无法修改这个类。

1
2
3
4
5
6
7
8

class Report {
  //...
  void sendReport() {
    Date nextDay = new Date(previousEnd.getYear(),
      previousEnd.getMonth(), previousEnd.getDate() + 1);
    //...
  }
}

解决

在客户类中建立一个函数，并一个第一个参数形式传入一个服务类实例。

1
2
3
4
5
6
7
8
9
10

class Report {
  //...
  void sendReport() {
    Date newStart = nextDay(previousEnd);
    //...
  }
  private static Date nextDay(Date arg) {
    return new Date(arg.getYear(), arg.getMonth(), arg.getDate() + 1);
  }
}

引入本地扩展(Introduce Local Extension)

问题

你需要为服务类提供一些额外函数，但你无法修改这个类。

解决

建立一个新类，使它包含这些额外函数，让这个扩展品成为源类的子类或包装类。

中间人

中间人(Middle Man)

如果一个类的作用仅仅是指向另一个类的委托，为什么要存在呢？

问题原因

对象的基本特征之一就是封装：对外部世界隐藏其内部细节。封装往往伴随委托。但是人们可能过度运用委托。比如，你也许会看到一个类的大部分有用工作都委托给了其他类，类本身成了一个空壳，除了委托之外不做任何事情。

解决方法

应该运用 移除中间人(Remove Middle Man)，直接和真正负责的对象打交道。

收益

• 减少笨重的代码。

何时忽略

如果是以下情况，不要删除已创建的中间人：

• 添加中间人是为了避免类之间依赖关系。
• 一些设计模式有目的地创建中间人（例如代理模式和装饰器模式）。

重构方法说明

移除中间人(Remove Middle Man)

问题

某个类做了过多的简单委托动作。

解决

让客户直接调用委托类。

依恋情结

依恋情结(Feature Envy)

一个函数访问其它对象的数据比访问自己的数据更多。

问题原因

这种气味可能发生在字段移动到数据类之后。如果是这种情况，你可能想将数据类的操作移动到这个类中。

解决方法

As a basic rule, if things change at the same time, you should keep them in the same place. Usually data and functions that use this data are changed together (although exceptions are possible).

有一个基本原则：同时会发生改变的事情应该被放在同一个地方。通常，数据和使用这些数据的函数是一起改变的。

• 如果一个函数明显应该被移到另一个地方，可运用 搬移函数(Move Method) 。
• 如果仅仅是函数的部分代码访问另一个对象的数据，运用 提炼函数(Extract Method) 将这部分代码移到独立的函数中。
• 如果一个方法使用来自其他几个类的函数，首先确定哪个类包含大多数使用的数据。然后，将该方法与其他数据一起放在此类中。或者，使用 提炼函数(Extract Method) 将方法拆分为几个部分，可以放置在不同类中的不同位置。

收益

• 减少重复代码（如果数据处理的代码放在中心位置）。
• 更好的代码组织性（处理数据的函数靠近实际数据）。

何时忽略

• 有时，行为被有意地与保存数据的类分开。这通常的优点是能够动态地改变行为（见策略设计模式，访问者设计模式和其他模式）。

重构方法说明

搬移函数(Move Method)

问题

你的程序中，有个函数与其所驻类之外的另一个类进行更多交流：调用后者，或被后者调用。

解决

在该函数最常引用的类中建立一个有着类似行为的新函数。将旧函数变成一个单纯的委托函数，或是旧函数完全移除。

提炼函数(Extract Method)

问题

你有一段代码可以组织在一起。

1
2
3
4
5
6
7

void printOwing() {
  printBanner();

  //print details
  System.out.println("name: " + name);
  System.out.println("amount: " + getOutstanding());
}

解决

移动这段代码到一个新的函数中，使用函数的调用来替代老代码。

1
2
3
4
5
6
7
8
9

void printOwing() {
  printBanner();
  printDetails(getOutstanding());
}

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

狎昵关系

狎昵关系(Inappropriate Intimacy)

一个类大量使用另一个类的内部字段和方法。

问题原因

类和类之间应该尽量少的感知彼此（减少耦合）。这样的类更容易维护和复用。

解决方法

• 最简单的解决方法是运用 搬移函数(Move Method) 和 搬移字段(Move Field) 来让类之间斩断羁绊。

• 你也可以看看是否能运用 将双向关联改为单向关联(Change Bidirectional Association to Unidirectional) 让其中一个类对另一个说分手。

• 如果这两个类实在是情比金坚，难分难舍，可以运用 提炼类(Extract Class) 把二者共同点提炼到一个新类中，让它们产生爱的结晶。或者，可以尝试运用 隐藏委托关系(Hide Delegate) 让另一个类来为它们牵线搭桥。

• 继承往往造成类之间过分紧密，因为子类对超类的了解总是超过后者的主观愿望，如果你觉得该让这个子类自己闯荡，请运用 以委托取代继承(Replace Inheritance with Delegation) 来让超类和子类分家。

收益

• 提高代码组织性。
• 提高代码复用性。

重构方法说明

搬移函数(Move Method)

问题

你的程序中，有个函数与其所驻类之外的另一个类进行更多交流：调用后者，或被后者调用。

解决

在该函数最常引用的类中建立一个有着类似行为的新函数。将旧函数变成一个单纯的委托函数，或是旧函数完全移除。

搬移字段(Move Field)

问题

在你的程序中，某个字段被其所驻类之外的另一个类更多地用到。

解决

在目标类新建一个字段，修改源字段的所有用户，令他们改用新字段。

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

问题

两个类之间有双向关联，但其中一个类如今不再需要另一个类的特性。

解决

去除不必要的关联。

提炼类(Extract Class)

问题

某个类做了不止一件事。

解决

建立一个新类，将相关的字段和函数从旧类搬移到新类。

隐藏委托关系(Hide Delegate)

问题

客户通过一个委托类来调用另一个对象。

解决

在服务类上建立客户所需的所有函数，用以隐藏委托关系。

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

问题

某个子类只使用超类接口中的一部分，或是根本不需要继承而来的数据。

解决

在子类中新建一个字段用以保存超类；调整子类函数，令它改而委托超类；然后去掉两者之间的继承关系。

过度耦合的消息链

过度耦合的消息链(Message Chains)

消息链的形式类似于：obj.getA().getB().getC()。

问题原因

如果你看到用户向一个对象请求另一个对象，然后再向后者请求另一个对象，然后再请求另一个对象……这就是消息链。实际代码中你看到的可能是一长串 getThis()或一长串临时变量。采取这种方式，意味客户代码将与查找过程中的导航紧密耦合。一旦对象间关系发生任何变化，客户端就不得不做出相应的修改。

解决方法

• 可以运用 隐藏委托关系(Hide Delegate) 删除一个消息链。

• 有时更好的选择是：先观察消息链最终得到的对象是用来干什么的。看看能否以 提炼函数(Extract Method)把使用该对象的代码提炼到一个独立函数中，再运用 搬移函数(Move Method) 把这个函数推入消息链。

收益

• 能减少链中类之间的依赖。
• 能减少代码量。

何时忽略

• 过于侵略性的委托可能会使程序员难以理解功能是如何触发的。

重构方法说明

隐藏委托关系(Hide Delegate)

问题

客户通过一个委托类来调用另一个对象。

解决

在服务类上建立客户所需的所有函数，用以隐藏委托关系。

提炼函数(Extract Method)

问题

你有一段代码可以组织在一起。

1
2
3
4
5
6
7

void printOwing() {
  printBanner();

  //print details
  System.out.println("name: " + name);
  System.out.println("amount: " + getOutstanding());
}

解决

移动这段代码到一个新的函数中，使用函数的调用来替代老代码。

1
2
3
4
5
6
7
8
9

void printOwing() {
  printBanner();
  printDetails(getOutstanding());
}

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

搬移函数(Move Method)

问题

你的程序中，有个函数与其所驻类之外的另一个类进行更多交流：调用后者，或被后者调用。

解决

在该函数最常引用的类中建立一个有着类似行为的新函数。将旧函数变成一个单纯的委托函数，或是旧函数完全移除。

扩展阅读

• 代码的坏味道和重构
• 代码坏味道之代码臃肿
• 代码坏味道之滥用面向对象
• 代码坏味道之变革的障碍
• 代码坏味道之非必要的
• 代码坏味道之耦合

参考资料

• 重构——改善既有代码的设计 - by Martin Fowler
• https://sourcemaking.com/refactoring

📦 本文已归档到：「blog」

翻译自：https://sourcemaking.com/refactoring/smells/dispensables

非必要的(Dispensables)这组坏味道意味着：这样的代码可有可无，它的存在反而影响整体代码的整洁和可读性。

冗余类

冗余类(Lazy Class)

理解和维护总是费时费力的。如果一个类不值得你花费精力，它就应该被删除。

问题原因

也许一个类的初始设计是一个功能完全的类，然而随着代码的变迁，变得没什么用了。
又或者类起初的设计是为了支持未来的功能扩展，然而却一直未派上用场。

解决方法

• 没什么用的类可以运用 将类内联化(Inline Class) 来干掉。

• 如果子类用处不大，试试 折叠继承体系(Collapse Hierarchy) 。

收益

• 减少代码量
• 易于维护

何时忽略

• 有时，创建冗余类是为了描述未来开发的意图。在这种情况下，尝试在代码中保持清晰和简单之间的平衡。

重构方法说明

将类内联化(Inline Class)

问题

某个类没有做太多事情。

解决

将这个类的所有特性搬移到另一个类中，然后移除原类。

折叠继承体系(Collapse Hierarchy)

问题

超类和子类之间无太大区别。

解决

将它们合为一体。

夸夸其谈未来性

夸夸其谈未来性(Speculative Generality)

存在未被使用的类、函数、字段或参数。

问题原因

有时，代码仅仅为了支持未来的特性而产生，然而却一直未实现。结果，代码变得难以理解和维护。

解决方法

• 如果你的某个抽象类其实没有太大作用，请运用 折叠继承体系(Collapse Hierarch) 。

• 不必要的委托可运用 将类内联化(Inline Class) 消除。
• 无用的函数可运用 内联函数(Inline Method) 消除。
• 函数中有无用的参数应该运用 移除参数(Remove Parameter) 消除。
• 无用字段可以直接删除。

收益

• 减少代码量。
• 更易维护。

何时忽略

• 如果你在一个框架上工作，创建框架本身没有使用的功能是非常合理的，只要框架的用户需要这个功能。
• 删除元素之前，请确保它们不在单元测试中使用。如果测试需要从类中获取某些内部信息或执行特殊的测试相关操作，就会发生这种情况。

重构方法说明

折叠继承体系(Collapse Hierarchy)

问题

超类和子类之间无太大区别。

解决

将它们合为一体。

将类内联化(Inline Class)

问题

某个类没有做太多事情。

解决

将这个类的所有特性搬移到另一个类中，然后移除原类。

内联函数(Inline Method)

问题

一个函数的本体比函数名更清楚易懂。

1
2
3
4
5
6
7
8
9

class PizzaDelivery {
  //...
  int getRating() {
    return moreThanFiveLateDeliveries() ? 2 : 1;
  }
  boolean moreThanFiveLateDeliveries() {
    return numberOfLateDeliveries > 5;
  }
}

解决

在函数调用点插入函数本体，然后移除该函数。

1
2
3
4
5
6

class PizzaDelivery {
  //...
  int getRating() {
    return numberOfLateDeliveries > 5 ? 2 : 1;
  }
}

移除参数(Remove Parameter)

问题

函数本体不再需要某个参数。

解决

将该参数去除。

纯稚的数据类

纯稚的数据类(Data Class) 指的是只包含字段和访问它们的 getter 和 setter 函数的类。这些仅仅是供其他类使用的数据容器。这些类不包含任何附加功能，并且不能对自己拥有的数据进行独立操作。

问题原因

当一个新创建的类只包含几个公共字段（甚至可能几个 getters / setters）是很正常的。但是对象的真正力量在于它们可以包含作用于数据的行为类型或操作。

解决方法

• 如果一个类有公共字段，你应该运用 封装字段(Encapsulated Field) 来隐藏字段的直接访问方式。
• 如果这些类含容器类的字段，你应该检查它们是不是得到了恰当的封装；如果没有，就运用 封装集合(Encapsulated Collection) 把它们封装起来。
• 找出这些 getter/setter 函数被其他类运用的地点。尝试以 搬移函数(Move Method) 把那些调用行为搬移到 纯稚的数据类(Data Class) 来。如果无法搬移这个函数，就运用 提炼函数(Extract Method) 产生一个可搬移的函数。

• 在类已经充满了深思熟虑的函数之后，你可能想要摆脱旧的数据访问方法，以提供适应面较广的类数据访问接口。为此，可以运用 移除设置函数(Remove Setting Method) 和 隐藏函数(Hide Method) 。

收益

• 提高代码的可读性和组织性。特定数据的操作现在被集中在一个地方，而不是在分散在代码各处。
• 帮助你发现客户端代码的重复处。

重构方法说明

封装字段(Encapsulated Field)

问题

你的类中存在 public 字段。

1
2
3

class Person {
  public String name;
}

解决

将它声明为 private，并提供相应的访问函数。

1
2
3
4
5
6
7
8
9
10

class Person {
  private String name;

  public String getName() {
    return name;
  }
  public void setName(String arg) {
    name = arg;
  }
}

封装集合(Encapsulated Collection)

问题

有个函数返回一个集合。

解决

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

搬移函数(Move Method)

问题

你的程序中，有个函数与其所驻类之外的另一个类进行更多交流：调用后者，或被后者调用。

解决

在该函数最常引用的类中建立一个有着类似行为的新函数。将旧函数变成一个单纯的委托函数，或是旧函数完全移除。

提炼函数(Extract Method)

问题

你有一段代码可以组织在一起。

1
2
3
4
5
6
7

void printOwing() {
  printBanner();

  //print details
  System.out.println("name: " + name);
  System.out.println("amount: " + getOutstanding());
}

解决

移动这段代码到一个新的函数中，使用函数的调用来替代老代码。

1
2
3
4
5
6
7
8
9

void printOwing() {
  printBanner();
  printDetails(getOutstanding());
}

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

移除设置函数(Remove Setting Method)

问题

类中的某个字段应该在对象创建时被设值，然后就不再改变。

解决

去掉该字段的所有设值函数。

隐藏函数(Hide Method)

问题

有一个函数，从来没有被其他任何类用到。

解决

将这个函数修改为 private。

过多的注释

过多的注释(Comments)

注释本身并不是坏事。但是常常有这样的情况：一段代码中出现长长的注释，而它之所以存在，是因为代码很糟糕。

问题原因

注释的作者意识到自己的代码不直观或不明显，所以想使用注释来说明自己的意图。这种情况下，注释就像是烂代码的除臭剂。

最好的注释是为函数或类起一个恰当的名字。

如果你觉得一个代码片段没有注释就无法理解，请先尝试重构，试着让所有注释都变得多余。

解决方法

• 如果一个注释是为了解释一个复杂的表达式，可以运用 提炼变量(Extract Variable) 将表达式切分为易理解的子表达式。
• 如果你需要通过注释来解释一段代码做了什么，请试试 提炼函数(Extract Method) 。
• 如果函数已经被提炼，但仍需要注释函数做了什么，试试运用 函数改名(Rename Method) 来为函数起一个可以自解释的名字。
• 如果需要对系统某状态进行断言，请运用 引入断言(Introduce Assertion) 。

收益

• 代码变得更直观和明显。

何时忽略

注释有时候很有用：

• 当解释为什么某事物要以特殊方式实现时。
• 当解释某种复杂算法时。
• 当你实在不知可以做些什么时。

重构方法说明

提炼变量(Extract Variable)

问题

你有个难以理解的表达式。

1
2
3
4
5
6
7
8

void renderBanner() {
  if ((platform.toUpperCase().indexOf("MAC") > -1) &&
       (browser.toUpperCase().indexOf("IE") > -1) &&
        wasInitialized() && resize > 0 )
  {
    // do something
  }
}

解决

将表达式的结果或它的子表达式的结果用不言自明的变量来替代。

1
2
3
4
5
6
7
8
9

void renderBanner() {
  final boolean isMacOs = platform.toUpperCase().indexOf("MAC") > -1;
  final boolean isIE = browser.toUpperCase().indexOf("IE") > -1;
  final boolean wasResized = resize > 0;

  if (isMacOs && isIE && wasInitialized() && wasResized) {
    // do something
  }
}

提炼函数(Extract Method)

问题

你有一段代码可以组织在一起。

1
2
3
4
5
6
7

void printOwing() {
  printBanner();

  //print details
  System.out.println("name: " + name);
  System.out.println("amount: " + getOutstanding());
}

解决

移动这段代码到一个新的函数中，使用函数的调用来替代老代码。

1
2
3
4
5
6
7
8
9

void printOwing() {
  printBanner();
  printDetails(getOutstanding());
}

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

函数改名(Rename Method)

问题

函数的名称未能恰当的揭示函数的用途。

1
2
3

class Person {
  public String getsnm();
}

解决

修改函数名。

1
2
3

class Person {
  public String getSecondName();
}

引入断言(Introduce Assertion)

问题

某一段代码需要对程序状态做出某种假设。

1
2
3
4
5
6

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.isTrue(expenseLimit != NULL_EXPENSE || primaryProject != null);

  return (expenseLimit != NULL_EXPENSE) ?
    expenseLimit:
    primaryProject.getMemberExpenseLimit();
}

注：请不要滥用断言。不要使用它来检查”应该为真“的条件，只能使用它来检查“一定必须为真”的条件。实际上，断言更多是用于自我检测代码的一种手段。在产品真正交付时，往往都会消除所有断言。

重复代码

重复代码(Duplicate Code)

重复代码堪称为代码坏味道之首。消除重复代码总是有利无害的。

问题原因

重复代码通常发生在多个程序员同时在同一程序的不同部分上工作时。由于他们正在处理不同的任务，他们可能不知道他们的同事已经写了类似的代码。

还有一种更隐晦的重复，特定部分的代码看上去不同但实际在做同一件事。这种重复代码往往难以找到和消除。

有时重复是有目的性的。当急于满足 deadline，并且现有代码对于要交付的任务是“几乎正确的”时，新手程序员可能无法抵抗复制和粘贴相关代码的诱惑。在某些情况下，程序员只是太懒惰。

解决方法

• 同一个类的两个函数含有相同的表达式，这时可以采用 提炼函数(Extract Method) 提炼出重复的代码，然后让这两个地点都调用被提炼出来的那段代码。

• 如果两个互为兄弟的子类含有重复代码：
  • 首先对两个类都运用 提炼函数(Extract Method) ，然后对被提炼出来的函数运用 函数上移(Pull Up Method) ，将它推入超类。
  • 如果重复代码在构造函数中，运用 构造函数本体上移(Pull Up Constructor Body) 。
  • 如果重复代码只是相似但不是完全相同，运用 塑造模板函数(Form Template Method) 获得一个 模板方法模式(Template Method) 。
  • 如果有些函数以不同的算法做相同的事，你可以选择其中较清晰地一个，并运用 替换算法(Substitute Algorithm) 将其他函数的算法替换掉。
• 如果两个毫不相关的类中有重复代码：
  • 请尝试运用 提炼超类(Extract Superclass) ，以便为维护所有先前功能的这些类创建一个超类。
  • 如果创建超类十分困难，可以在一个类中运用 提炼类(Extract Class) ，并在另一个类中使用这个新的组件。
• 如果存在大量的条件表达式，并且它们执行完全相同的代码（仅仅是它们的条件不同），可以运用 合并条件表达式(Consolidate Conditional Expression) 将这些操作合并为单个条件，并运用 提炼函数(Extract Method) 将该条件放入一个名字容易理解的独立函数中。
• 如果条件表达式的所有分支都有部分相同的代码片段：可以运用 合并重复的条件片段(Consolidate Duplicate Conditional Fragments) 将它们都存在的代码片段置于条件表达式外部。

收益

• 合并重复代码会简化代码的结构，并减少代码量。
• 代码更简化、更易维护。

重构方法说明

提炼函数(Extract Method)

问题

你有一段代码可以组织在一起。

1
2
3
4
5
6
7

void printOwing() {
  printBanner();

  //print details
  System.out.println("name: " + name);
  System.out.println("amount: " + getOutstanding());
}

解决

移动这段代码到一个新的函数中，使用函数的调用来替代老代码。

1
2
3
4
5
6
7
8
9

void printOwing() {
  printBanner();
  printDetails(getOutstanding());
}

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

函数上移(Pull Up Method)

问题

有些函数，在各个子类中产生完全相同的结果。

解决

将该函数移至超类。

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

问题

你在各个子类中拥有一些构造函数，它们的本体几乎完全一致。

1
2
3
4
5
6
7
8

class Manager extends Employee {
  public Manager(String name, String id, int grade) {
    this.name = name;
    this.id = id;
    this.grade = grade;
  }
  //...
}

解决

在超类中新建一个构造函数，并在子类构造函数中调用它。

1
2
3
4
5
6
7

class Manager extends Employee {
  public Manager(String name, String id, int grade) {
    super(name, id);
    this.grade = grade;
  }
  //...
}

塑造模板函数(Form Template Method)

问题

你有一些子类，其中相应的某些函数以相同的顺序执行类似的操作，但各个操作的细节上有所不同。

解决

将这些操作分别放进独立函数中，并保持它们都有相同的签名，于是原函数也就变得相同了。然后将原函数上移至超类。

注：这里只提到具体做法，建议了解一下模板方法设计模式。

替换算法(Substitute Algorithm)

问题

你想要把某个算法替换为另一个更清晰的算法。

1
2
3
4
5
6
7
8
9
10
11
12
13
14

String foundPerson(String[] people){
  for (int i = 0; i < people.length; i++) {
    if (people[i].equals("Don")){
      return "Don";
    }
    if (people[i].equals("John")){
      return "John";
    }
    if (people[i].equals("Kent")){
      return "Kent";
    }
  }
  return "";
}

解决

将函数本体替换为另一个算法。

1
2
3
4
5
6
7
8
9
10

String foundPerson(String[] people){
  List candidates =
    Arrays.asList(new String[] {"Don", "John", "Kent"});
  for (int i=0; i < people.length; i++) {
    if (candidates.contains(people[i])) {
      return people[i];
    }
  }
  return "";
}

提炼超类(Extract Superclass)

问题

两个类有相似特性。

解决

为这两个类建立一个超类，将相同特性移至超类。

提炼类(Extract Class)

问题

某个类做了不止一件事。

解决

建立一个新类，将相关的字段和函数从旧类搬移到新类。

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

问题

你有一系列条件分支，都得到相同结果。

1
2
3
4
5
6
7
8
9
10
11
12
13

double disabilityAmount() {
  if (seniority < 2) {
    return 0;
  }
  if (monthsDisabled > 12) {
    return 0;
  }
  if (isPartTime) {
    return 0;
  }
  // compute the disability amount
  //...
}

解决

将这些条件分支合并为一个条件，并将这个条件提炼为一个独立函数。

1
2
3
4
5
6
7

double disabilityAmount() {
  if (isNotEligableForDisability()) {
    return 0;
  }
  // compute the disability amount
  //...
}

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

问题

在条件表达式的每个分支上有着相同的一段代码。

1
2
3
4
5
6
7
8

if (isSpecialDeal()) {
  total = price * 0.95;
  send();
}
else {
  total = price * 0.98;
  send();
}

解决

将这段重复代码搬移到条件表达式之外。

1
2
3
4
5
6
7

if (isSpecialDeal()) {
  total = price * 0.95;
}
else {
  total = price * 0.98;
}
send();

扩展阅读

• 代码的坏味道和重构
• 代码坏味道之代码臃肿
• 代码坏味道之滥用面向对象
• 代码坏味道之变革的障碍
• 代码坏味道之非必要的
• 代码坏味道之耦合

参考资料

• 重构——改善既有代码的设计 - by Martin Fowler
• https://sourcemaking.com/refactoring

📦 本文已归档到：「blog」

第一次读《重构:改善既有代码的设计》时，我曾整理过一个简单的笔记。最近，因为参与一个重构项目，再一次温习了《重构:改善既有代码的设计》。过程中，萌发了认真总结、整理重构方法的冲动，于是有了这系列文字。

代码的坏味道还有几篇没有完稿，后面我会陆续补充。。。

症与药

对代码的坏味道的思考

“有病要早治，不要放弃治疗”。多么朴素的道理 ，人人都懂。

病，就是不健康。

人有病，可以通过打针、吃药、做手术来进行治疗。

如果把代码的坏味道（代码质量问题）比作病症，那么重构就是治疗代码的坏味道的药。

个人认为，在重构这件事上，也可以应用治病的道理：

• 防病于未然。
  —— 春秋战国时期的一代名医扁鹊，曾经有个很著名的医学主张：防病于未然。 我觉得这个道理应用于软件代码的重构亦然。编程前要有合理的设计、编程时要有良好的编程风格，尽量减少问题。从这个层面上说，了解代码的坏味道，不仅仅是为了发现问题、解决问题。更重要的作用是：指导我们在编程过程中有意识的去规避这些问题。

• 小病不医，易得大病。
  —— 刘备说过：“勿以善小而不为，勿以恶小而为之”。发现问题就及时修改，代码质量自然容易进入良性循环；反之，亦然。要重视积累的力量，别总以为代码出现点小问题，那都不是事儿。

• 对症下药。
  —— 程序出现了问题，要分析出问题的根本，有针对性的制定合理的重构方案。大家都知道吃错药的后果，同样的，瞎改还不如不改。

• 忌猛药
  —— 医病用猛药容易产生副作用。换一句俗语：步子大了容易扯着蛋。重构如果大刀阔斧的干，那你就要有随时可能扑街的心理准备。推倒重来不是重构，而是重写。重构应该是循序渐进，步步为营的过程。当你发现重写代码比重构代码更简单，往往说明你早就该重构了。

重构的原则

前面把代码质量问题比作病症，而把重构比作药。这里，我们再进一步讨论一下重构的原则。

何谓重构(What)

重构（Refactoring） 的常见定义是：不改变软件系统外部行为的前提下，改善它的内部结构。

个人觉得这个定义有点生涩。不妨理解为：重构是给代码治病的行为。而代码有病是指代码的质量（可靠性、安全性、可复用性、可维护性）和性能有问题。

重构的目的是为了提高代码的质量和性能。

注：功能不全或者不正确，那是残疾代码。就像治病治不了残疾，重构也解决不了功能问题。

为何重构(Why)

翻翻书，上网搜一下，谈到重构的理由大体相同：

• 重构改进软件设计
• 重构使软件更容易理解
• 重构帮助找到 bug
• 重构提高编程速度

总之就是，重构可以提高代码质量。

何时重构(When)

关于何时重构，我先引用一下 重构并非难在如何做，而是难在何时开始做 一文的观点。

对于一个高速发展的公司来说，停止业务开发，专门来做重构项目，从来就不是一个可接受的选项，“边开飞机边换引擎”才是这种公司想要的。

我们不妨来衡量一下重构的成本和收益。

• 重构的成本

  重构是有成本的，费时费力（时间、人力）不说，还有可能会使本来正常运行的程序出错。所以，很多人都抱着“不求有功，但求无过”的心理得过且过。

  还有一种成本：重构使用较新且较为复杂的技术，学习曲线不平滑，团队成员技术切换困难，短期内开发效率可能不升反降。

  但是，如果一直放任代码腐朽下去，技术债务会越来越沉重。当代码最终快要跑不动时，架构师们往往还是不得不使用激进的手段来治疗代码的顽疾。但是，这个过程通常都是非常痛苦的，而且有着很高的失败风险。

• 重构的收益

  重构的收益是提高代码的质量和性能，并提高未来的开发效率。但是，应当看到，重构往往并不能在短期内带来实际的效益，或者很难直观看出效益。而对于一个企业来说，没有什么比效益更重要。换句话说，没有实际效益的事，通常也没有价值。很多领导，尤其是非技术方向的领导，并不关心你应用了什么新技术，让代码变得多么优雅等等。

• 重构的合适时机

  从以上来看，重构实在是个吃力不讨好的事情。

  于是，很多人屈服于万恶的 KPI 和要命的 deadline，一边吐槽着以前的代码是垃圾，一边自己也在造垃圾。

  但是，重构本应该是个渐进式的过程，不是只有伤筋动骨的改造才叫重构。如果非要等到代码已经烂到病入膏肓，再使用激进方式来重构，那必然是困难重重，风险极高。

  《重构》书中提到的重构时机应该在添加功能、修复功能、审查代码时，不建议专门抽出时间专门做重构项目。

  我认为，其思想就是指：重构应该是在开发过程中实时的、渐进的演化过程。

• 重构的不恰当时机

  但是，这里我也要强调一下：不是所有软件开发过程都一定要重构。

  较能凸显重构价值的场景是：代码规模较大、生命周期还较长、承担了较多责任、有一个较大（且较不稳定，人员流动频繁）团队在其上工作的单一代码库。

  与之相反，有一些场景的重构价值就很小：

  • 代码库生命周期快要走到尾声，开发逐渐减少，以维护为主。
  • 代码库当前版本马上要发布了，这时重构无疑是给自己找麻烦。
  • 重构代价过于沉重：重构后功能的正确性、稳定性难以保障；技术过于超前，团队成员技术迁移难度太大。

如何重构(How)

重构行为在我看来，也是可以分层级的。由高到低，越高层级难度越大：

• 服务、数据库
  现代软件往往业务复杂、庞大。使用微服务、数据迁移来拆分业务，降低业务复杂度成为了主流。但是，这些技术的测试、部署复杂，技术难度很高。

• 组件、模块、框架
  组件、模块、框架的重构，主要是针对代码的设计问题。解决的是代码的整体结构问题。需要对框架、设计模式、分布式、并发等等有足够的了解。

• 类、接口、函数、字段
  《重构》一书提到了“代码的坏味道”以及相关的重构方法。这些都是对类、接口、函数、字段级别代码的重构手段。由于这一级别的重构方法较为简单，所以可操作性较强。具体细节可以阅读《代码的坏味道》篇章。

前两种层级的重构已经涉及到架构层面，影响较大，难度较高，如果功力不够不要轻易变动。由于这两个层级涉及领域较广，这里不做论述。

此处为分割线。下面是代码的坏味道系列。。。

代码的坏味道

《重构:改善既有代码的设计》中介绍了 22 种代码的坏味道以及重构手法。这些坏味道可以进一步归类。我总觉得将事物分类有助于理解和记忆。所以本系列将坏味道按照特性分类，然后逐一讲解。

代码坏味道之代码臃肿

代码臃肿(Bloated)这组坏味道意味着：代码中的类、函数、字段没有经过合理的组织，只是简单的堆砌起来。这一类型的问题通常在代码的初期并不明显，但是随着代码规模的增长而逐渐积累（特别是当没有人努力去根除它们时）。

• 过长函数
• 过大的类
• 基本类型偏执
• 过长参数列
• 数据泥团

代码坏味道之滥用面向对象

滥用面向对象(Object-Orientation Abusers)这组坏味道意味着：代码部分或完全地违背了面向对象编程原则。

• switch 声明
• 临时字段
• 被拒绝的馈赠
• 异曲同工的类

代码坏味道之变革的障碍

变革的障碍(Change Preventers)这组坏味道意味着：当你需要改变一处代码时，却发现不得不改变其他的地方。这使得程序开发变得复杂、代价高昂。

• 发散式变化
• 霰弹式修改
• 平行继承体系

代码坏味道之非必要的

非必要的(Dispensables)这组坏味道意味着：这样的代码可有可无，它的存在反而影响整体代码的整洁和可读性。

• 过多的注释
• 重复代码
• 冗余类
• 纯稚的数据类
• 夸夸其谈未来性

代码坏味道之耦合

耦合(Couplers)这组坏味道意味着：不同类之间过度耦合。

• 依恋情结
• 狎昵关系
• 过度耦合的消息链
• 中间人
• 不完美的库类

扩展阅读

• 代码的坏味道和重构
• 代码坏味道之代码臃肿
• 代码坏味道之滥用面向对象
• 代码坏味道之变革的障碍
• 代码坏味道之非必要的
• 代码坏味道之耦合

参考资料

• 重构——改善既有代码的设计 - by Martin Fowler
• https://sourcemaking.com/refactoring

经过两个月的迷茫和爬坑，我小吴又回来了，本文总结下 RPC 的简单实现。

本文代码：GitHub

Flume

Sqoop 是一个主要在 Hadoop 和关系数据库之间进行批量数据迁移的工具。

• Flume 简介
  • 什么是 Flume ？
  • 应用场景
• Flume 原理
  • Flume 基本概念
  • Flume 基本组件
  • Flume 数据流
• 资源

Flume 简介

什么是 Flume ？

Flume 是一个分布式海量数据采集、聚合和传输系统。

特点

• 基于事件的海量数据采集
• 数据流模型：Source -> Channel -> Sink
• 事务机制：支持重读重写，保证消息传递的可靠性
• 内置丰富插件：轻松与各种外部系统集成
• 高可用：Agent 主备切换
• Java 实现：开源，优秀的系统设计

应用场景

Flume 原理

Flume 基本概念

• Event：事件，最小数据传输单元，由 Header 和 Body 组成。
• Agent：代理，JVM 进程，最小运行单元，由 Source、Channel、Sink 三个基本组件构成，负责将外部数据源产生的数据以 Event 的形式传输到目的地
  • Source：负责对接各种外部数据源，将采集到的数据封装成 Event，然后写入 Channel
  • Channel：Event 暂存容器，负责保存 Source 发送的 Event，直至被 Sink 成功读取
  • Sink：负责从 Channel 读取 Event，然后将其写入外部存储，或传输给下一阶段的 Agent
  • 映射关系：1 个 Source -> 多个 Channel，1 个 Channel -> 多个 Sink，1 个 Sink -> 1 个 Channel

Flume 基本组件

Source 组件

• 对接各种外部数据源，将采集到的数据封装成 Event，然后写入 Channel
• 一个 Source 可向多个 Channel 发送 Event
• Flume 内置类型丰富的 Source，同时用户可自定义 Source

Channel 组件

• Event 中转暂存区，存储 Source 采集但未被 Sink 读取的 Event
• 为了平衡 Source 采集、Sink 读取的速度，可视为 Flume 内部的消息队列
• 线程安全并具有事务性，支持 Source 写失败重写和 Sink 读失败重读

Sink 组件

• 从 Channel 读取 Event，将其写入外部存储，或传输到下一阶段的 Agent
• 一个 Sink 只能从一个 Channel 中读取 Event
• Sink 成功读取 Event 后，向 Channel 提交事务，Event 被删除，否则 Channel 会等待 Sink 重新读取

Flume 数据流

单层架构

优点：架构简单，使用方便，占用资源较少
缺点
如果采集的数据源或Agent较多，将Event写入到HDFS会产生很多小文件
外部存储升级维护或发生故障，需对采集层的所有Agent做处理，人力成本较高，系统稳定性较差
系统安全性较差
数据源管理较混乱

资源

Sqoop

Sqoop 是一个主要在 Hadoop 和关系数据库之间进行批量数据迁移的工具。

• Sqoop 简介
  • 提供多种 Sqoop 连接器
  • Sqoop 版本
• Sqoop 原理
  • 导入
  • 导出

Sqoop 简介

Sqoop 是一个主要在 Hadoop 和关系数据库之间进行批量数据迁移的工具。

• Hadoop：HDFS、Hive、HBase、Inceptor、Hyperbase
• 面向大数据集的批量导入导出
• 将输入数据集分为 N 个切片，然后启动 N 个 Map 任务并行传输
• 支持全量、增量两种传输方式

提供多种 Sqoop 连接器

内置连接器

• 经过优化的专用 RDBMS 连接器：MySQL、PostgreSQL、Oracle、DB2、SQL Server、Netzza 等
• 通用的 JDBC 连接器：支持 JDBC 协议的数据库

第三方连接器

• 数据仓库：Teradata
• NoSQL 数据库：Couchbase

Sqoop 版本

Sqoop 1 优缺点

优点

• 架构简单
• 部署简单
• 功能全面
• 稳定性较高
• 速度较快

缺点

• 访问方式单一
• 命令行方式容易出错，格式紧耦合
• 安全机制不够完善，存在密码泄露风险

Sqoop 2 优缺点

优点

• 访问方式多样
• 集中管理连接器
• 安全机制较完善
• 支持多用户

缺点

• 架构较复杂
• 部署较繁琐
• 稳定性一般
• 速度一般

Sqoop 原理

导入

导出

MapReduce

• MapReduce 简介
  • 概念
  • 思想
  • 特点
  • 适用场景
  • 不适用场景
• MapReduce 原理
  • Job & Task（作业与任务）
  • Split（切片）
  • Map 阶段（映射）
  • Reduce 阶段（化简）
  • Shuffle 阶段（洗牌）
• Shuffle 详解
  • Map 端
  • Reduce 端
• 作业运行模式
  • JobTracker/TaskTracker 模式（Hadoop 1.X）
  • YARN 模式（Hadoop 2.X）

MapReduce 简介

概念

MapReduce 是一个面向批处理的分布式计算框架。

编程模型：MapReduce 程序被分为 Map（映射）阶段和 Reduce（化简）阶段。

思想

分而治之，并行计算
移动计算，而非移动数据

特点

• 计算跟着数据走
• 良好的扩展性：计算能力随着节点数增加，近似线性递增
• 高容错
• 状态监控
• 适合海量数据的离线批处理
• 降低了分布式编程的门槛

适用场景

• 数据统计，如：网站的 PV、UV 统计
• 搜索引擎构建索引
• 海量数据查询

不适用场景

• OLAP
  • 要求毫秒或秒级返回结果
• 流计算
  • 流计算的输入数据集是动态的，而 MapReduce 是静态的
• DAG 计算
  • 多个作业存在依赖关系，后一个的输入是前一个的输出，构成有向无环图 DAG
  • 每个 MapReduce 作业的输出结果都会落盘，造成大量磁盘 IO，导致性能非常低下

MapReduce 原理

Job & Task（作业与任务）

• 作业是客户端请求执行的一个工作单元
  • 包括输入数据、MapReduce 程序、配置信息
• 任务是将作业分解后得到的细分工作单元
  • 分为 Map 任务和 Reduce 任务

Split（切片）

• 输入数据被划分成等长的小数据块，称为输入切片（Input Split），简称切片
• Split 是逻辑概念，仅包含元数据信息，如：数据的起始位置、长度、所在节点等
• 每个 Split 交给一个 Map 任务处理，Split 的数量决定 Map 任务的数量
• Split 的划分方式由程序设定，Split 与 HDFS Block 没有严格的对应关系
• Split 的大小默认等于 Block 大小
• Split 越小，负载越均衡，但集群的开销越大

Map 阶段（映射）

• 由若干 Map 任务组成，任务数量由 Split 数量决定
• 输入：Split 切片（key-value），输出：中间计算结果（key-value）

Reduce 阶段（化简）

• 由若干 Reduce 任务组成，任务数量由程序指定
• 输入：Map 阶段输出的中间结果（key-value），输出：最终结果（key-value）

Shuffle 阶段（洗牌）

• Map、Reduce 阶段的中间环节，负责执行 Partition（分区）、Sort（排序）、Spill（溢写）、Merge（合并）、抓取（Fetch）等工作
• Partition 决定了 Map 任务输出的每条数据放入哪个分区，交给哪个 Reduce 任务处理
• Reduce 任务的数量决定了 Partition 数量
• Partition 编号 = Reduce 任务编号 =“key hashcode % reduce task number”
• 避免和减少 Shuffle 是 MapReduce 程序调优的重点

Shuffle 详解

Map 端

Map 任务将中间结果写入专用内存缓冲区 Buffer（默认 100M），同时进行 Partition 和 Sort（先按“key hashcode % reduce task number”对数据进行分区，分区内再按 key 排序）
当 Buffer 的数据量达到阈值（默认 80%）时，将数据溢写（Spill）到磁盘的一个临时文件中，文件内数据先分区后排序
Map 任务结束前，将多个临时文件合并（Merge）为一个 Map 输出文件，文件内数据先分区后排序

Reduce 端

Reduce 任务从多个 Map 输出文件中主动抓取（Fetch）属于自己的分区数据，先写入 Buffer，数据量达到阈值后，溢写到磁盘的一个临时文件中
数据抓取完成后，将多个临时文件合并为一个 Reduce 输入文件，文件内数据按 key 排序

作业运行模式

JobTracker/TaskTracker 模式（Hadoop 1.X）

JobTracker 节点（Master）

• 调度任务在 TaskTracker 上运行
• 若任务失败，指定新 TaskTracker 重新运行

TaskTracker 节点（Slave）

• 执行任务，发送进度报告

存在的问题

• JobTracker 存在单点故障
• JobTracker 负载太重（上限 4000 节点）
• JobTracker 缺少对资源的全面管理
• TaskTracker 对资源的描述过于简单
• 源码很难理解

YARN 模式（Hadoop 2.X）

• 提交作业
• 查看作业
• 终止作业

HDFS

HDFS 是 Hadoop 分布式文件系统。

关键词：分布式、文件系统

• 概述
  • HDFS 的特点
• HDFS 的概念
  • NameNode
  • DataNode
  • Block 数据块
  • Client
• Block 副本策略
• 数据流
  • HDFS 读文件
  • HDFS 写文件
• HDFS 安全模式
  • 什么是安全模式？
  • 何时正常离开安全模式
  • 触发安全模式的原因
  • 故障排查
• HDFS 高可用
  • NameNode 的 HA 机制
  • 利用 QJM 实现元数据高可用
• 资源

概述

HDFS 是 Hadoop 的核心子项目。

HDFS 是 Hadoop Distributed File System 的缩写，即 Hadoop 分布式文件系统。

HDFS 是一种用于存储具有流数据访问模式的超大文件的文件系统，它运行在廉价的机器集群上。

HDFS 的特点

优点

• 高容错 - 数据冗余多副本，副本丢失后自动恢复
• 高可用 - NameNode HA、安全模式
• 高扩展 - 能够处理 10K 节点的规模；处理数据达到 GB、TB、甚至 PB 级别的数据；能够处理百万规模以上的文件数量，数量相当之大。
• 批处理 - 流式数据访问；数据位置暴露给计算框架
• 构建在廉价商用机器上 - 提供了容错和恢复机制

缺点

• 不适合低延迟数据访问 - 适合高吞吐率的场景，就是在某一时间内写入大量的数据。但是它在低延时的情况下是不行的，比如毫秒级以内读取数据，它是很难做到的。
• 不适合大量小文件存储
  • 存储大量小文件(这里的小文件是指小于 HDFS 系统的 Block 大小的文件（默认 64M）)的话，它会占用 NameNode 大量的内存来存储文件、目录和块信息。这样是不可取的，因为 NameNode 的内存总是有限的。
  • 磁盘寻道时间超过读取时间
• 不支持并发写入 - 一个文件同时只能有一个写入者
• 不支持文件随机修改 - 仅支持追加写入

HDFS 的概念

HDFS 采用 Master/Slave 架构。

一个 HDFS 集群是由一个 Namenode 和一定数目的 Datanodes 组成。Namenode 是一个中心服务器，负责管理文件系统的名字空间(namespace)以及客户端对文件的访问。集群中的 Datanode 一般是一个节点一个，负责管理它所在节点上的存储。HDFS 暴露了文件系统的名字空间，用户能够以文件的形式在上面存储数据。从内部看，一个文件其实被分成一个或多个数据块，这些块存储在一组 Datanode 上。Namenode 执行文件系统的名字空间操作，比如打开、关闭、重命名文件或目录。它也负责确定数据块到具体 Datanode 节点的映射。Datanode 负责处理文件系统客户端的读写请求。在 Namenode 的统一调度下进行数据块的创建、删除和复制。

NameNode

NameNode 就是 master 工作节点。

• 管理命名空间
• 管理元数据：文件的位置、所有者、权限、数据块等
• 管理 Block 副本策略：默认 3 个副本
• 处理客户端读写请求，为 DataNode 分配任务

Active NameNode 和 Standby NameNode

NameNode 通过 HA 机制来容错。

• Active NameNode - 是正在工作的 NameNode；
• Standby NameNode - 是备份的 NameNode。

Active NameNode 宕机后，Standby NameNode 快速升级为新的 Active NameNode。

Standby NameNode 周期性同步 edits 编辑日志，定期合并 fsimage 与 edits 到本地磁盘。

Hadoop 3.0 允许配置多个 Standby NameNode。

元数据文件

• edits（编辑日志文件） - 保存了自最新检查点（Checkpoint）之后的所有文件更新操作。
• fsimage（元数据检查点镜像文件） - 保存了文件系统中所有的目录和文件信息，如：某个目录下有哪些子目录和文件，以及文件名、文件副本数、文件由哪些 Block 组成等。

Active NameNode 内存中有一份最新的元数据（= fsimage + edits）。

Standby NameNode 在检查点定期将内存中的元数据保存到 fsimage 文件中。

DataNode

DataNode 就是 slave 工作节点。NameNode 下达命令，DataNode 执行实际的操作。

• 存储 Block 和数据校验和
• 执行客户端发送的读写操作
• 通过心跳机制定期（默认 3 秒）向 NameNode 汇报运行状态和 Block 列表信息
• 集群启动时，DataNode 向 NameNode 提供 Block 列表信息

Block 数据块

• HDFS 最小存储单元
• 文件写入 HDFS 会被切分成若干个 Block
• Block 大小固定，默认为 128MB，可自定义
• 若一个 Block 的大小小于设定值，不会占用整个块空间
• 默认情况下每个 Block 有 3 个副本

Client

• 将文件切分为 Block 数据块
• 与 NameNode 交互，获取文件元数据
• 与 DataNode 交互，读取或写入数据
• 管理 HDFS

Block 副本策略

HDFS 被设计成能够在一个大集群中跨机器可靠地存储超大文件。它将每个文件存储成一系列的数据块，除了最后一个，所有的数据块都是同样大小的。为了容错，文件的所有数据块都会有副本。每个文件的数据块大小和副本系数都是可配置的。应用程序可以指定某个文件的副本数目。副本系数可以在文件创建的时候指定，也可以在之后改变。HDFS 中的文件都是一次性写入的，并且严格要求在任何时候只能有一个写入者。

Namenode 全权管理数据块的复制，它周期性地从集群中的每个 Datanode 接收心跳信号和块状态报告(Blockreport)。接收到心跳信号意味着该 Datanode 节点工作正常。块状态报告包含了一个该 Datanode 上所有数据块的列表。

• 副本 1：放在 Client 所在节点
  • 对于远程 Client，系统会随机选择节点
• 副本 2：放在不同的机架节点上
• 副本 3：放在与第二个副本同一机架的不同节点上
• 副本 N：随机选择
• 节点选择：同等条件下优先选择空闲节点

数据流

HDFS 读文件

1. 客户端调用 FileSyste 对象的 open() 方法在分布式文件系统中打开要读取的文件。
2. 分布式文件系统通过使用 RPC（远程过程调用）来调用 namenode，确定文件起始块的位置。
3. 分布式文件系统的 DistributedFileSystem 类返回一个支持文件定位的输入流 FSDataInputStream 对象，FSDataInputStream 对象接着封装 DFSInputStream 对象（存储着文件起始几个块的 datanode 地址），客户端对这个输入流调用 read()方法。
4. DFSInputStream 连接距离最近的 datanode，通过反复调用 read 方法，将数据从 datanode 传输到客户端。
5. 到达块的末端时，DFSInputStream 关闭与该 datanode 的连接，寻找下一个块的最佳 datanode。
6. 客户端完成读取，对 FSDataInputStream 调用 close()方法关闭连接。

HDFS 写文件

1. 客户端通过对 DistributedFileSystem 对象调用 create() 函数来新建文件。
2. 分布式文件系统对 namenod 创建一个 RPC 调用，在文件系统的命名空间中新建一个文件。
3. Namenode 对新建文件进行检查无误后，分布式文件系统返回给客户端一个 FSDataOutputStream 对象，FSDataOutputStream 对象封装一个 DFSoutPutstream 对象，负责处理 namenode 和 datanode 之间的通信，客户端开始写入数据。
4. FSDataOutputStream 将数据分成一个一个的数据包，写入内部队列“数据队列”，DataStreamer 负责将数据包依次流式传输到由一组 namenode 构成的管线中。
5. DFSOutputStream 维护着确认队列来等待 datanode 收到确认回执，收到管道中所有 datanode 确认后，数据包从确认队列删除。
6. 客户端完成数据的写入，对数据流调用 close() 方法。
7. namenode 确认完成。

HDFS 安全模式

什么是安全模式？

• 安全模式是 HDFS 的一种特殊状态，在这种状态下，HDFS 只接收读数据请求，而不接收写入、删除、修改等变更请求。
• 安全模式是 HDFS 确保 Block 数据安全的一种保护机制。
• Active NameNode 启动时，HDFS 会进入安全模式，DataNode 主动向 NameNode 汇报可用 Block 列表等信息，在系统达到安全标准前，HDFS 一直处于“只读”状态。

何时正常离开安全模式

• Block 上报率：DataNode 上报的可用 Block 个数 / NameNode 元数据记录的 Block 个数
• 当 Block 上报率 >= 阈值时，HDFS 才能离开安全模式，默认阈值为 0.999
• 不建议手动强制退出安全模式

触发安全模式的原因

• NameNode 重启
• NameNode 磁盘空间不足
• Block 上报率低于阈值
• DataNode 无法正常启动
• 日志中出现严重异常
• 用户操作不当，如：强制关机（特别注意！）

故障排查

• 找到 DataNode 不能正常启动的原因，重启 DataNode
• 清理 NameNode 磁盘
• 谨慎操作，有问题找星环，以免丢失数据

HDFS 高可用

NameNode 的 HA 机制

Active NameNode 和 Standby NameNode 实现主备。

利用 QJM 实现元数据高可用

基于 Paxos 算法

QJM 机制（Quorum Journal Manager）

只要保证 Quorum（法定人数）数量的操作成功，就认为这是一次最终成功的操作

QJM 共享存储系统

• 部署奇数（2N+1）个 JournalNode
• JournalNode 负责存储 edits 编辑日志
• 写 edits 的时候，只要超过半数（N+1）的 JournalNode 返回成功，就代表本次写入成功
• 最多可容忍 N 个 JournalNode 宕机

利用 ZooKeeper 实现 Active 节点选举。

资源

• HDFS 官方文档
• HDFS 知识点总结
• 《Hadoop: The Definitive Guide, Fourth Edition》 by Tom White
• http://hadoop.apache.org/docs/r1.0.4/cn/hdfs_design.html