重构: 改善既有代码设计 - 第二版 第11–12章

已于 2024-10-30 10:21:06 修改
阅读量901 收藏 26
点赞数 12
文章标签： 重构
于 2024-10-30 09:59:56 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/csdn_life18/article/details/143357259
版权

重构: 改善既有代码设计 - 第二版 第11–12章

下载地址：https://wwbf.lanzouw.com/iKbPZ2dpsxmj

第 11 章 重构 API

模块和函数是软件的骨肉，而 API 则是将骨肉连接起来的关节。易于理解和使用的 API 非常重要，但同时也很难获得。随着对软件理解的加深，我会学到如何改进 API，这时我便需要对 API 进行重构。

好的 API 会把更新数据的函数与只是读取数据的函数清晰分开。如果我看到这两类操作被混在一起，就会用将查询函数和修改函数分离（306）将它们分开。如果两个函数的功能非常相似、只有一些数值不同，我可以用函数参数化（310）将其统一。但有些参数其实只是一个标记，根据这个标记的不同，函数会有截然不同的行为，此时最好用移除标记参数（314）将不同的行为彻底分开。

在函数间传递时，数据结构常会毫无必要地被拆开，我更愿意用保持对象完整（319）将其聚拢。函数需要的一份信息，究竟何时应该作为参数传入、何时应该调用一个函数获得，这是一个需要反复推敲的决定，推敲的过程中常常要用到以查询取代参数（324）和以参数取代查询（327）。

类是一种常见的模块形式。我希望尽可能保持对象不可变，所以只要有可能，我就会使用移除设值函数（331）。当调用者要求一个新对象时，我经常需要比构造函数更多的灵活性，可以借助以工厂函数取代构造函数（334）获得这种灵活性。

有时你会遇到一个特别复杂的函数，围绕着它传入传出一大堆数据。最后两个重构手法专门用于破解这个难题。我可以用以命令取代函数（337）将这个函数变成对象，这样对函数体使用提炼函数（106）时会更容易。如果稍后我对该函数做了简化，不再需要将其作为命令对象了，可以用以函数取代命令（344）再把它变回函数。

11.1 将查询函数和修改函数分离（Separate Query from Modifier）

function getTotalOutstandingAndSendBill() {
const result = customer.invoices.reduce((total, each) => each.amount + total, 0);
sendBill();
return result;
}


function totalOutstanding() {
return customer.invoices.reduce((total, each) => each.amount + total, 0);
}
function sendBill() {
emailGateway.send(formatBill(customer));
}

动机

如果某个函数只是提供一个值，没有任何看得到的副作用，那么这是一个很有价值的东西。我可以任意调用这个函数，也可以把调用动作搬到调用函数的其他地方。这种函数的测试也更容易。简而言之，需要操心的事情少多了。

明确表现出“有副作用”与“无副作用”两种函数之间的差异，是个很好的想法。下面是一条好规则：任何有返回值的函数，都不应该有看得到的副作用——命令与查询分离（Command-Query Separation）[mf-cqs]。有些程序员甚至将此作为一条必须遵守的规则。就像对待任何东西一样，我并不绝对遵守它，不过我总是尽量遵守，而它也回报我很好的效果。

如果遇到一个“既有返回值又有副作用”的函数，我就会试着将查询动作从修改动作中分离出来。

你也许已经注意到了：我使用“看得到的副作用”这种说法。有一种常见的优化办法是：将查询所得结果缓存于某个字段中，这样一来后续的重复查询就可以大大加快速度。虽然这种做法改变了对象中缓存的状态，但这一修改是察觉不到的，因为不论如何查询，总是获得相同结果。

做法

复制整个函数，将其作为一个查询来命名。

如果想不出好名字，可以看看函数返回的是什么。查询的结果会被填入一个变量，这个变量的名字应该能对函数如何命名有所启发。

从新建的查询函数中去掉所有造成副作用的语句。

执行静态检查。

查找所有调用原函数的地方。如果调用处用到了该函数的返回值，就将其改为调用新建的查询函数，并在下面马上再调用一次原函数。每次修改之后都要测试。

从原函数中去掉返回值。

测试。

完成重构之后，查询函数与原函数之间常会有重复代码，可以做必要的清理。

范例

有这样一个函数：它会遍历一份恶棍（miscreant）名单，检查一群人（people）里是否混进了恶棍。如果发现了恶棍，该函数会返回恶棍的名字，并拉响警报。如果人群中有多名恶棍，该函数也只汇报找出的第一名恶棍（我猜这就已经够了）。

function alertForMiscreant(people) {
  for (const p of people) {
    if (p === "Don") {
      setOffAlarms();
      return "Don";
    }
    if (p === "John") {
      setOffAlarms();
      return "John";
    }
  }
  return "";
}

首先我复制整个函数，用它的查询部分功能为其命名。

function findMiscreant(people) {
  for (const p of people) {
    if (p === "Don") {
      setOffAlarms();
      return "Don";
    }
    if (p === "John") {
      setOffAlarms();
      return "John";
    }
  }
  return "";
}

然后在新建的查询函数中去掉副作用。

function findMiscreant(people) {
  for (const p of people) {
    if (p === "Don") {
      setOffAlarms();
      return "Don";
    }
    if (p === "John") {
      setOffAlarms();
      return "John";
    }
  }
  return "";
}

然后找到所有原函数的调用者，将其改为调用新建的查询函数，并在其后调用一次修改函数（也就是原函数）。于是代码

const found = alertForMiscreant(people);

就变成了

const found = findMiscreant(people);
alertForMiscreant(people);

现在可以从修改函数中去掉所有返回值了。

function alertForMiscreant(people) {
  for (const p of people) {
    if (p === "Don") {
      setOffAlarms();
      return;
    }
    if (p === "John") {
      setOffAlarms();
      return;
    }
  }
  return;
}

现在，原来的修改函数和新建的查询函数之间有大量的重复代码，我可以使用替换算法（195），让修改函数使用查询函数。

function alertForMiscreant(people) {
  if (findMiscreant(people) !== "") setOffAlarms();
}

11.2 函数参数化（Parameterize Function）

曾用名：令函数携带参数（Parameterize Method）

function tenPercentRaise(aPerson) {
  aPerson.salary = aPerson.salary.multiply(1.1);
}
function fivePercentRaise(aPerson) {
  aPerson.salary = aPerson.salary.multiply(1.05);
}

function raise(aPerson, factor) {
  aPerson.salary = aPerson.salary.multiply(1 + factor);
}

动机

如果我发现两个函数逻辑非常相似，只有一些字面量值不同，可以将其合并成一个函数，以参数的形式传入不同的值，从而消除重复。这个重构可以使函数更有用，因为重构后的函数还可以用于处理其他的值。

做法

从一组相似的函数中选择一个。

运用改变函数声明（124），把需要作为参数传入的字面量添加到参数列表中。

修改该函数所有的调用处，使其在调用时传入该字面量值。

测试。

修改函数体，令其使用新传入的参数。每使用一个新参数都要测试。

对于其他与之相似的函数，逐一将其调用处改为调用已经参数化的函数。每次修改后都要测试。

如果第一个函数经过参数化以后不能直接替代另一个与之相似的函数，就先对参数化之后的函数做必要的调整，再做替换。

范例

下面是一个显而易见的例子：

function tenPercentRaise(aPerson) {
  aPerson.salary = aPerson.salary.multiply(1.1);
}
function fivePercentRaise(aPerson) {
  aPerson.salary = aPerson.salary.multiply(1.05);
}

很明显我可以用下面这个函数来替换上面两个：

function raise(aPerson, factor) {
  aPerson.salary = aPerson.salary.multiply(1 + factor);
}

情况可能比这个更复杂一些。例如下列代码：

function baseCharge(usage) {
 if (usage < 0) return usd(0);
 const amount =
    bottomBand(usage) * 0.03
    + middleBand(usage) * 0.05
    + topBand(usage) * 0.07;
 return usd(amount);
}

function bottomBand(usage) {
 return Math.min(usage, 100);
}

function middleBand(usage) {
 return usage > 100 ? Math.min(usage, 200) - 100 : 0;
}

function topBand(usage) {
 return usage > 200 ? usage - 200 : 0;
}

这几个函数中的逻辑明显很相似，但是不是相似到足以支撑一个参数化的计算“计费档次”（band）的函数？这次就不像前面第一个例子那样一目了然了。

在尝试对几个相关的函数做参数化操作时，我会先从中挑选一个，在上面添加参数，同时留意其他几种情况。在类似这样处理“范围”的情况下，通常从位于中间的范围开始着手较好。所以我首先选择了 middleBand 函数来添加参数，然后调整其他的调用者来适应它。

middleBand 使用了两个字面量值，即 100 和 200，分别代表“中间档次”的下界和上界。我首先用改变函数声明（124）加上这两个参数，同时顺手给函数改个名，使其更好地表述参数化之后的含义。

function withinBand(usage, bottom, top) {
 return usage > 100 ? Math.min(usage, 200) - 100 : 0;
}

function baseCharge(usage) {
 if (usage < 0) return usd(0);
 const amount =
    bottomBand(usage) * 0.03
    + withinBand(usage, 100, 200) * 0.05
    + topBand(usage) * 0.07;
 return usd(amount);
}

在函数体内部，把一个字面量改为使用新传入的参数：

function withinBand(usage, bottom, top) {
  return usage & gt;
  bottom ? Math.min(usage, 200) - bottom : 0;
}

然后是另一个：

function withinBand(usage, bottom, top) {
  return usage & gt;
  bottom ? Math.min(usage, top) - bottom : 0;
}

对于原本调用 bottomBand 函数的地方，我将其改为调用参数化了的新函数。

function baseCharge(usage) {
 if (usage < 0) return usd(0);
 const amount =
    withinBand(usage, 0, 100) * 0.03
    + withinBand(usage, 100, 200) * 0.05
    + topBand(usage) * 0.07;
 return usd(amount);
}

function bottomBand(usage) {
 return Math.min(usage, 100);
}

为了替换对 topBand 的调用，我就得用代表“无穷大”的 Infinity 作为这个范围的上界。

function baseCharge(usage) {
 if (usage < 0) return usd(0);
 const amount =
    withinBand(usage, 0, 100) * 0.03
    + withinBand(usage, 100, 200) * 0.05
    + withinBand(usage, 200, Infinity) * 0.07;
 return usd(amount);
}

function topBand(usage) {
  return usage > 200 ? usage - 200 : 0;
}

照现在的逻辑，baseCharge 一开始的卫语句已经可以去掉了。不过，尽管这条语句已经失去了逻辑上的必要性，我还是愿意把它留在原地，因为它阐明了“传入的 usage 参数为负数”这种情况是如何处理的。

11.3 移除标记参数（Remove Flag Argument）

曾用名：以明确函数取代参数（Replace Parameter with Explicit Methods）

function setDimension(name, value) {
  if (name === "height") {
    this._height = value;
    return;
  }
  if (name === "width") {
    this._width = value;
    return;
  }
}

function setHeight(value) {
  this._height = value;
}
function setWidth(value) {
  this._width = value;
}

动机

“标记参数”是这样的一种参数：调用者用它来指示被调函数应该执行哪一部分逻辑。例如，我可能有下面这样一个函数：

function bookConcert(aCustomer, isPremium) {
  if (isPremium) {
    // logic for premium booking
  } else {
    // logic for regular booking
  }
}

要预订一场高级音乐会（premium concert），就得这样发起调用：

bookConcert(aCustomer, true);

标记参数也可能以枚举的形式出现：

bookConcert(aCustomer, CustomerType.PREMIUM);

或者是以字符串（或者符号，如果编程语言支持的话）的形式出现：

bookConcert(aCustomer, "premium");

我不喜欢标记参数，因为它们让人难以理解到底有哪些函数可以调用、应该怎么调用。拿到一份 API 以后，我首先看到的是一系列可供调用的函数，但标记参数却隐藏了函数调用中存在的差异性。使用这样的函数，我还得弄清标记参数有哪些可用的值。布尔型的标记尤其糟糕，因为它们不能清晰地传达其含义——在调用一个函数时，我很难弄清 true 到底是什么意思。如果明确用一个函数来完成一项单独的任务，其含义会清晰得多。

premiumBookConcert(aCustomer);

并非所有类似这样的参数都是标记参数。如果调用者传入的是程序中流动的数据，这样的参数不算标记参数；只有调用者直接传入字面量值，这才是标记参数。另外，在函数实现内部，如果参数值只是作为数据传给其他函数，这就不是标记参数；只有参数值影响了函数内部的控制流，这才是标记参数。

移除标记参数不仅使代码更整洁，并且能帮助开发工具更好地发挥作用。去掉标记参数后，代码分析工具能更容易地体现出“高级”和“普通”两种预订逻辑在使用时的区别。

如果一个函数有多个标记参数，可能就不得不将其保留，否则我就得针对各个参数的各种取值的所有组合情况提供明确函数。不过这也是一个信号，说明这个函数可能做得太多，应该考虑是否能用更简单的函数来组合出完整的逻辑。

做法

针对参数的每一种可能值，新建一个明确函数。

如果主函数有清晰的条件分发逻辑，可以用分解条件表达式（260）创建明确函数；否则，可以在原函数之上创建包装函数。

对于“用字面量值作为参数”的函数调用者，将其改为调用新建的明确函数。

范例

在浏览代码时，我发现多处代码在调用一个函数计算物流（shipment）的到货日期（delivery date）。一些调用代码类似这样：

aShipment.deliveryDate = deliveryDate(anOrder, true);

另一些调用代码则是这样：

aShipment.deliveryDate = deliveryDate(anOrder, false);

面对这样的代码，我立即开始好奇：参数里这个布尔值是什么意思？是用来干什么的？

deliveryDate 函数主体如下所示：

function deliveryDate(anOrder, isRush) {
  if (isRush) {
    let deliveryTime;
    if (["MA", "CT"].includes(anOrder.deliveryState)) deliveryTime = 1;
    else if (["NY", "NH"].includes(anOrder.deliveryState)) deliveryTime = 2;
    else deliveryTime = 3;
    return anOrder.placedOn.plusDays(1 + deliveryTime);
  } else {
    let deliveryTime;
    if (["MA", "CT", "NY"].includes(anOrder.deliveryState)) deliveryTime = 2;
    else if (["ME", "NH"].includes(anOrder.deliveryState)) deliveryTime = 3;
    else deliveryTime = 4;
    return anOrder.placedOn.plusDays(2 + deliveryTime);
  }
}

原来调用者用这个布尔型字面量来判断应该运行哪个分支的代码——典型的标记参数。然而函数的重点就在于要遵循调用者的指令，所以最好是用明确函数的形式明确说出调用者的意图。

对于这个例子，我可以使用分解条件表达式（260），得到下列代码：

function deliveryDate(anOrder, isRush) {
  if (isRush) return rushDeliveryDate(anOrder);
  else return regularDeliveryDate(anOrder);
}
function rushDeliveryDate(anOrder) {
  let deliveryTime;
  if (["MA", "CT"].includes(anOrder.deliveryState)) deliveryTime = 1;
  else if (["NY", "NH"].includes(anOrder.deliveryState)) deliveryTime = 2;
  else deliveryTime = 3;
  return anOrder.placedOn.plusDays(1 + deliveryTime);
}
function regularDeliveryDate(anOrder) {
  let deliveryTime;
  if (["MA", "CT", "NY"].includes(anOrder.deliveryState)) deliveryTime = 2;
  else if (["ME", "NH"].includes(anOrder.deliveryState)) deliveryTime = 3;
  else deliveryTime = 4;
  return anOrder.placedOn.plusDays(2 + deliveryTime);
}

这两个函数能更好地表达调用者的意图，现在我可以修改调用方代码了。调用代码

aShipment.deliveryDate = deliveryDate(anOrder, true);

可以改为

aShipment.deliveryDate = rushDeliveryDate(anOrder);

另一个分支也类似。

处理完所有调用处，我就可以移除 deliveryDate 函数。

这个参数是标记参数，不仅因为它是布尔类型，而且还因为调用方以字面量的形式直接设置参数值。如果所有调用 deliveryDate 的代码都像这样：

const isRush = determineIfRush(anOrder);
aShipment.deliveryDate = deliveryDate(anOrder, isRush);

那我对这个函数的签名没有任何意见（不过我还是想用分解条件表达式（260）清理其内部实现）。

可能有一些调用者给这个参数传入的是字面量，将其作为标记参数使用；另一些调用者则传入正常的数据。若果真如此，我还是会使用移除标记参数（314），但不修改传入正常数据的调用者，重构结束时也不删除 deliveryDate 函数。这样我就提供了两套接口，分别支持不同的用途。

直接拆分条件逻辑是实施本重构的好方法，但只有当“根据参数值做分发”的逻辑发生在函数最外层（或者可以比较容易地将其重构至函数最外层）的时候，这一招才好用。函数内部也有可能以一种更纠结的方式使用标记参数，例如下面这个版本的 deliveryDate 函数：

function deliveryDate(anOrder, isRush) {
 let result;
 let deliveryTime;
 if (anOrder.deliveryState === "MA" || anOrder.deliveryState === "CT")
  deliveryTime = isRush? 1 : 2;
 else if (anOrder.deliveryState === "NY" || anOrder.deliveryState === "NH") {
  deliveryTime = 2;
  if (anOrder.deliveryState === "NH" &amp;&amp; !isRush)
   deliveryTime = 3;
 }
 else if (isRush)
  deliveryTime = 3;
 else if (anOrder.deliveryState === "ME")
  deliveryTime = 3;
 else
  deliveryTime = 4;
 result = anOrder.placedOn.plusDays(2 + deliveryTime);
 if (isRush) result = result.minusDays(1);
 return result;
}

这种情况下，想把围绕 isRush 的分发逻辑剥离到顶层，需要的工作量可能会很大。所以我选择退而求其次，在 deliveryDate 之上添加两个函数：

function rushDeliveryDate(anOrder) {
  return deliveryDate(anOrder, true);
}
function regularDeliveryDate(anOrder) {
  return deliveryDate(anOrder, false);
}

本质上，这两个包装函数分别代表了 deliveryDate 函数一部分的使用方式。不过它们并非从原函数中拆分而来，而是用代码文本强行定义的。

随后，我同样可以逐一替换原函数的调用者，就跟前面分解条件表达式之后的处理一样。如果没有任何一个调用者向 isRush 参数传入正常的数据，我最后会限制原函数的可见性，或是将其改名（例如改为 deliveryDateHelperOnly），让人一见即知不应直接使用这个函数。

11.4 保持对象完整（Preserve Whole Object）

const low = aRoom.daysTempRange.low;
const high = aRoom.daysTempRange.high;
if (aPlan.withinRange(low, high))


if (aPlan.withinRange(aRoom.daysTempRange))

动机

如果我看见代码从一个记录结构中导出几个值，然后又把这几个值一起传递给一个函数，我会更愿意把整个记录传给这个函数，在函数体内部导出所需的值。

“传递整个记录”的方式能更好地应对变化：如果将来被调的函数需要从记录中导出更多的数据，我就不用为此修改参数列表。并且传递整个记录也能缩短参数列表，让函数调用更容易看懂。如果有很多函数都在使用记录中的同一组数据，处理这部分数据的逻辑常会重复，此时可以把这些处理逻辑搬移到完整对象中去。

也有时我不想采用本重构手法，因为我不想让被调函数依赖完整对象，尤其是在两者不在同一个模块中的时候。

从一个对象中抽取出几个值，单独对这几个值做某些逻辑操作，这是一种代码坏味道（依恋情结），通常标志着这段逻辑应该被搬移到对象中。保持对象完整经常发生在引入参数对象（140）之后，我会搜寻使用原来的数据泥团的代码，代之以使用新的对象。

如果几处代码都在使用对象的一部分功能，可能意味着应该用提炼类（182）把这一部分功能单独提炼出来。

还有一种常被忽视的情况：调用者将自己的若干数据作为参数，传递给被调用函数。这种情况下，我可以将调用者的自我引用（在 JavaScript 中就是 this）作为参数，直接传递给目标函数。

做法

新建一个空函数，给它以期望中的参数列表（即传入完整对象作为参数）。

给这个函数起一个容易搜索的名字，这样到重构结束时方便替换。

在新函数体内调用旧函数，并把新的参数（即完整对象）映射到旧的参数列表（即来源于完整对象的各项数据）。

执行静态检查。

逐一修改旧函数的调用者，令其使用新函数，每次修改之后执行测试。

修改之后，调用处用于“从完整对象中导出参数值”的代码可能就没用了，可以用移除死代码（237）去掉。

所有调用处都修改过来之后，使用内联函数（115）把旧函数内联到新函数体内。

给新函数改名，从重构开始时的容易搜索的临时名字，改为使用旧函数的名字，同时修改所有调用处。

范例

我们想象一个室温监控系统，它负责记录房间一天中的最高温度和最低温度，然后将实际的温度范围与预先规定的温度控制计划（heating plan）相比较，如果当天温度不符合计划要求，就发出警告。

调用方…
const low = aRoom.daysTempRange.low;
const high = aRoom.daysTempRange.high;
if (!aPlan.withinRange(low, high))
  alerts.push("room temperature went outside range");
class HeatingPlan…
withinRange(bottom, top) {
 return (bottom >= this._temperatureRange.low) &amp;&amp; (top <= this._temperatureRange.high);
}

其实我不必将“温度范围”的信息拆开来单独传递，只需将整个范围对象传递给 withinRange 函数即可。

首先，我在 HeatingPlan 类中新添一个空函数，给它赋予我认为合理的参数列表。

class HeatingPlan…
xxNEWwithinRange(aNumberRange) {
}

因为这个函数最终要取代现有的 withinRange 函数，所以它也用了同样的名字，再加上一个容易替换的前缀。

然后在新函数体内调用现有的 withinRange 函数。因此，新函数体就完成了从新参数列表到旧函数参数列表的映射。

class HeatingPlan…
xxNEWwithinRange(aNumberRange) {
  return this.withinRange(aNumberRange.low, aNumberRange.high);
}

现在开始正式的替换工作了，我要找到调用现有函数的地方，将其改为调用新函数。

调用方…
const low = aRoom.daysTempRange.low;
const high = aRoom.daysTempRange.high;
if (!aPlan.xxNEWwithinRange(aRoom.daysTempRange))
  alerts.push("room temperature went outside range");

在修改调用处时，我可能会发现一些代码在修改后已经不再需要，此时可以使用移除死代码（237）。

调用方…
const low = aRoom.daysTempRange.low;
const high = aRoom.daysTempRange.high;
if (!aPlan.xxNEWwithinRange(aRoom.daysTempRange))
  alerts.push("room temperature went outside range");

每次替换一处调用代码，每次修改后都要测试。

调用处全部替换完成后，用内联函数（115）将旧函数内联到新函数体内。

class HeatingPlan…
xxNEWwithinRange(aNumberRange) {
 return (aNumberRange.low >= this._temperatureRange.low) &amp;&amp;
  (aNumberRange.high <= this._temperatureRange.high);
}

终于可以去掉新函数那难看的前缀了，记得同时修改所有调用者。就算我所使用的开发环境不支持可靠的函数改名操作，有这个极具特色的前缀在，我也可以很方便地全局替换。

class HeatingPlan…
withinRange(aNumberRange) {
 return (aNumberRange.low >= this._temperatureRange.low) &amp;&amp;
  (aNumberRange.high <= this._temperatureRange.high);
}
调用方…
if (!aPlan.withinRange(aRoom.daysTempRange))
  alerts.push("room temperature went outside range");

范例：换个方式创建新函数

在上面的示例中，我直接编写了新函数。大多数时候，这一步非常简单，也是创建新函数最容易的方式。不过有时还会用到另一种方式：可以完全通过重构手法的组合来得到新函数。

我从一处调用现有函数的代码开始。

调用方…
const low = aRoom.daysTempRange.low;
const high = aRoom.daysTempRange.high;
if (!aPlan.withinRange(low, high))
  alerts.push("room temperature went outside range");

我要先对代码做一些整理，以便用提炼函数（106）来创建新函数。目前的调用者代码还不具备可提炼的函数雏形，不过我可以先做几次提炼变量（119），使其轮廓显现出来。首先，我要把对旧函数的调用从条件判断中解放出来。

调用方…
const low = aRoom.daysTempRange.low;
const high = aRoom.daysTempRange.high;
const isWithinRange = aPlan.withinRange(low, high);
if (!isWithinRange) alerts.push("room temperature went outside range");

然后把输入参数也提炼出来。

调用方…
const tempRange = aRoom.daysTempRange;
const low = tempRange.low;
const high = tempRange.high;
const isWithinRange = aPlan.withinRange(low, high);
if (!isWithinRange) alerts.push("room temperature went outside range");

完成这一步之后，就可以用提炼函数（106）来创建新函数。

调用方…
const tempRange = aRoom.daysTempRange;
const isWithinRange = xxNEWwithinRange(aPlan, tempRange);
if (!isWithinRange) alerts.push("room temperature went outside range");
顶层作用域…
function xxNEWwithinRange(aPlan, tempRange) {
  const low = tempRange.low;
  const high = tempRange.high;
  const isWithinRange = aPlan.withinRange(low, high);
  return isWithinRange;
}

由于旧函数属于另一个上下文（HeatingPlan 类），我需要用搬移函数（198）把新函数也搬过去。

调用方…
const tempRange = aRoom.daysTempRange;
const isWithinRange = aPlan.xxNEWwithinRange(tempRange);
if (!isWithinRange) alerts.push("room temperature went outside range");
class HeatingPlan…
xxNEWwithinRange(tempRange) {
  const low = tempRange.low;
  const high = tempRange.high;
  const isWithinRange = this.withinRange(low, high);
  return isWithinRange;
}

剩下的过程就跟前面一样了：替换其他调用者，然后把旧函数内联到新函数中。重构刚开始的时候，为了清晰分离函数调用，以便提炼出新函数，我提炼了几个变量出来，现在可以把这些变量也内联回去。

这种方式的好处在于：它完全是由其他重构手法组合而成的。如果我使用的开发工具支持可靠的提炼和内联操作，用这种方式进行本重构会特别流畅。

11.5 以查询取代参数（Replace Parameter with Query）

曾用名：以函数取代参数（Replace Parameter with Method）

反向重构：以参数取代查询（327）

availableVacation(anEmployee, anEmployee.grade);

function availableVacation(anEmployee, grade) {
  // calculate vacation...


  availableVacation(anEmployee)

function availableVacation(anEmployee) {
  const grade = anEmployee.grade;
  // calculate vacation...

动机

函数的参数列表应该总结该函数的可变性，标示出函数可能体现出行为差异的主要方式。和任何代码中的语句一样，参数列表应该尽量避免重复，并且参数列表越短就越容易理解。

如果调用函数时传入了一个值，而这个值由函数自己来获得也是同样容易，这就是重复。这个本不必要的参数会增加调用者的难度，因为它不得不找出正确的参数值，其实原本调用者是不需要费这个力气的。

“同样容易”四个字，划出了一条判断的界限。去除参数也就意味着“获得正确的参数值”的责任被转移：有参数传入时，调用者需要负责获得正确的参数值；参数去除后，责任就被转移给了函数本身。一般而言，我习惯于简化调用方，因此我愿意把责任移交给函数本身，但如果函数难以承担这份责任，就另当别论了。

不使用以查询取代参数最常见的原因是，移除参数可能会给函数体增加不必要的依赖关系——迫使函数访问某个程序元素，而我原本不想让函数了解这个元素的存在。这种“不必要的依赖关系”除了新增的以外，也可能是我想要稍后去除的，例如为了去除一个参数，我可能会在函数体内调用一个有问题的函数，或是从一个对象中获取某些原本想要剥离出去的数据。在这些情况下，都应该慎重考虑使用以查询取代参数。

如果想要去除的参数值只需要向另一个参数查询就能得到，这是使用以查询取代参数最安全的场景。如果可以从一个参数推导出另一个参数，那么几乎没有任何理由要同时传递这两个参数。

另外有一件事需要留意：如果在处理的函数具有引用透明性（referential transparency，即，不论任何时候，只要传入相同的参数值，该函数的行为永远一致），这样的函数既容易理解又容易测试，我不想使其失去这种优秀品质。我不会去掉它的参数，让它去访问一个可变的全局变量。

做法

如果有必要，使用提炼函数（106）将参数的计算过程提炼到一个独立的函数中。

将函数体内引用该参数的地方改为调用新建的函数。每次修改后执行测试。

全部替换完成后，使用改变函数声明（124）将该参数去掉。

范例

某些重构会使参数不再被需要，这是我最常用到以查询取代参数的场合。考虑下列代码。

class Order…
get finalPrice() {
 const basePrice = this.quantity * this.itemPrice;
 let discountLevel;
 if (this.quantity > 100) discountLevel = 2;
 else discountLevel = 1;
 return this.discountedPrice(basePrice, discountLevel);
}

discountedPrice(basePrice, discountLevel) {
 switch (discountLevel) {
  case 1: return basePrice * 0.95;
  case 2: return basePrice * 0.9;
 }
}

在简化函数逻辑时，我总是热衷于使用以查询取代临时变量（178），于是就得到了如下代码。

class Order…
get finalPrice() {
 const basePrice = this.quantity * this.itemPrice;
 return this.discountedPrice(basePrice, this.discountLevel);
}

get discountLevel() {
 return (this.quantity > 100) ? 2 : 1;
}

到这一步，已经不需要再把 discountLevel 的计算结果传给 discountedPrice 了，后者可以自己调用 discountLevel 函数，不会增加任何难度。

因此，我把 discountedPrice 函数中用到这个参数的地方全都改为直接调用 discountLevel 函数。

class Order…
discountedPrice(basePrice, discountLevel) {
 switch (this.discountLevel) {
  case 1: return basePrice * 0.95;
  case 2: return basePrice * 0.9;
 }
}

然后用改变函数声明（124）手法移除该参数。

class Order…
get finalPrice() {
 const basePrice = this.quantity * this.itemPrice;
 return this.discountedPrice(basePrice, this.discountLevel);
}

discountedPrice(basePrice, discountLevel) {
 switch (this.discountLevel) {
  case 1: return basePrice * 0.95;
  case 2: return basePrice * 0.9;
 }
}

11.6 以参数取代查询（Replace Query with Parameter）

反向重构：以查询取代参数（324）

  targetTemperature(aPlan)

function targetTemperature(aPlan) {
  currentTemperature = thermostat.currentTemperature;
  // rest of function...


  targetTemperature(aPlan, thermostat.currentTemperature)

function targetTemperature(aPlan, currentTemperature) {
  // rest of function...

动机

在浏览函数实现时，我有时会发现一些令人不快的引用关系，例如，引用一个全局变量，或者引用另一个我想要移除的元素。为了解决这些令人不快的引用，我需要将其替换为函数参数，从而将处理引用关系的责任转交给函数的调用者。

需要使用本重构的情况大多源于我想要改变代码的依赖关系——为了让目标函数不再依赖于某个元素，我把这个元素的值以参数形式传递给该函数。这里需要注意权衡：如果把所有依赖关系都变成参数，会导致参数列表冗长重复；如果作用域之间的共享太多，又会导致函数间依赖过度。我一向不善于微妙的权衡，所以“能够可靠地改变决定”就显得尤为重要，这样随着我的理解加深，程序也能从中受益。

如果一个函数用同样的参数调用总是给出同样的结果，我们就说这个函数具有“引用透明性”（referential transparency），这样的函数理解起来更容易。如果一个函数使用了另一个元素，而后者不具引用透明性，那么包含该元素的函数也就失去了引用透明性。只要把“不具引用透明性的元素”变成参数传入，函数就能重获引用透明性。虽然这样就把责任转移给了函数的调用者，但是具有引用透明性的模块能带来很多益处。有一个常见的模式：在负责逻辑处理的模块中只有纯函数，其外再包裹处理 I/O 和其他可变元素的逻辑代码。借助以参数取代查询，我可以提纯程序的某些组成部分，使其更容易测试、更容易理解。

不过以参数取代查询并非只有好处。把查询变成参数以后，就迫使调用者必须弄清如何提供正确的参数值，这会增加函数调用者的复杂度，而我在设计接口时通常更愿意让接口的消费者更容易使用。归根到底，这是关于程序中责任分配的问题，而这方面的决策既不容易，也不会一劳永逸——这就是我需要非常熟悉本重构（及其反向重构）的原因。

做法

对执行查询操作的代码使用提炼变量（119），将其从函数体中分离出来。

现在函数体代码已经不再执行查询操作（而是使用前一步提炼出的变量），对这部分代码使用提炼函数（106）。

给提炼出的新函数起一个容易搜索的名字，以便稍后改名。

使用内联变量（123），消除刚才提炼出来的变量。

对原来的函数使用内联函数（115）。

对新函数改名，改回原来函数的名字。

范例

我们想象一个简单却又烦人的温度控制系统。用户可以从一个温控终端（thermostat）指定温度，但指定的目标温度必须在温度控制计划（heating plan）允许的范围内。

class HeatingPlan…
get targetTemperature() {
  if (thermostat.selectedTemperature > this._max) return this._max;
  else if (thermostat.selectedTemperature < this._min) return this._min;
  else return thermostat.selectedTemperature;
}
调用方…
if (thePlan.targetTemperature > thermostat.currentTemperature) setToHeat();
else if (thePlan.targetTemperature<thermostat.currentTemperature)setToCool();
else setOff();

系统的温控计划规则抑制了我的要求，作为这样一个系统的用户，我可能会感到很烦恼。不过作为程序员，我更担心的是 targetTemperature 函数依赖于全局的 thermostat 对象。我可以把需要这个对象提供的信息作为参数传入，从而打破对该对象的依赖。

首先，我要用提炼变量（119）把“希望作为参数传入的信息”提炼出来。

class HeatingPlan…
get targetTemperature() {
 const selectedTemperature = thermostat.selectedTemperature;
 if      (selectedTemperature > this._max) return this._max;
 else if (selectedTemperature < this._min) return this._min;
 else return selectedTemperature;
}

这样可以比较容易地用提炼函数（106）把整个函数体提炼出来，只剩“计算参数值”的逻辑还在原地。

class HeatingPlan…
get targetTemperature() {
 const selectedTemperature = thermostat.selectedTemperature;
 return this.xxNEWtargetTemperature(selectedTemperature);
}

xxNEWtargetTemperature(selectedTemperature) {
 if      (selectedTemperature > this._max) return this._max;
 else if (selectedTemperature < this._min) return this._min;
 else return selectedTemperature;
}

然后把刚才提炼出来的变量内联回去，于是旧函数就只剩一个简单的调用。

class HeatingPlan…
get targetTemperature() {
  return this.xxNEWtargetTemperature(thermostat.selectedTemperature);
}

现在可以对其使用内联函数（115）。

调用方…
if (thePlan.xxNEWtargetTemperature(thermostat.selectedTemperature) >
   thermostat.currentTemperature)
 setToHeat();
else if (thePlan.xxNEWtargetTemperature(thermostat.selectedTemperature) <
     thermostat.currentTemperature)
 setToCool();
else
 setOff();

再把新函数改名，用回旧函数的名字。得益于之前给它起了一个容易搜索的名字，现在只要把前缀去掉就行。

调用方…
if (thePlan.targetTemperature(thermostat.selectedTemperature) >
   thermostat.currentTemperature)
 setToHeat();
else if (thePlan.targetTemperature(thermostat.selectedTemperature) <
     thermostat.currentTemperature)
 setToCool();
else
 setOff();
class HeatingPlan…
targetTemperature(selectedTemperature) {
 if (selectedTemperature > this._max) return this._max;
 else if (selectedTemperature < this._min) return this._min;
 else return selectedTemperature;
}

调用方的代码看起来比重构之前更笨重了，这是使用本重构手法的常见情况。将一个依赖关系从一个模块中移出，就意味着将处理这个依赖关系的责任推回给调用者。这是为了降低耦合度而付出的代价。

但是，去除对 thermostat 对象的耦合，并不是本重构带来的唯一收益。HeatingPlan 类本身是不可变的——字段的值都在构造函数中设置，任何函数都不会修改它们。（不用费心去查看整个类的代码，相信我就好。）在不可变的 HeatingPlan 基础上，把对 thermostat 的依赖移出函数体之后，我又使 targetTemperature 函数具备了引用透明性。从此以后，只要在同一个 HeatingPlan 对象上用同样的参数调用 targetTemperature 函数，我会始终得到同样的结果。如果 HeatingPlan 的所有函数都具有引用透明性，这个类会更容易测试，其行为也更容易理解。

JavaScript 的类模型有一个问题：无法强制要求类的不可变性——始终有办法修改对象的内部数据。尽管如此，在编写一个类的时候明确说明并鼓励不可变性，通常也就足够了。尽量让类保持不可变通常是一个好的策略，以参数取代查询则是达成这一策略的利器。

11.7 移除设值函数（Remove Setting Method）

class Person {
get name() {...}
set name(aString) {...}


class Person {
get name() {...}

动机

如果为某个字段提供了设值函数，这就暗示这个字段可以被改变。如果不希望在对象创建之后此字段还有机会被改变，那就不要为它提供设值函数（同时将该字段声明为不可变）。这样一来，该字段就只能在构造函数中赋值，我“不想让它被修改”的意图会更加清晰，并且可以排除其值被修改的可能性——这种可能性往往是非常大的。

有两种常见的情况需要讨论。一种情况是，有些人喜欢始终通过访问函数来读写字段值，包括在构造函数内也是如此。这会导致构造函数成为设值函数的唯一使用者。若果真如此，我更愿意去除设值函数，清晰地表达“构造之后不应该再更新字段值”的意图。

另一种情况是，对象是由客户端通过创建脚本构造出来，而不是只有一次简单的构造函数调用。所谓“创建脚本”，首先是调用构造函数，然后就是一系列设值函数的调用，共同完成新对象的构造。创建脚本执行完以后，这个新生对象的部分（乃至全部）字段就不应该再被修改。设值函数只应该在起初的对象创建过程中调用。对于这种情况，我也会想办法去除设值函数，更清晰地表达我的意图。

做法

如果构造函数尚无法得到想要设入字段的值，就使用改变函数声明（124）将这个值以参数的形式传入构造函数。在构造函数中调用设值函数，对字段设值。

如果想移除多个设值函数，可以一次性把它们的值都传入构造函数，这能简化后续步骤。

移除所有在构造函数之外对设值函数的调用，改为使用新的构造函数。每次修改之后都要测试。

如果不能把“调用设值函数”替换为“创建一个新对象”（例如你需要更新一个多处共享引用的对象），请放弃本重构。

使用内联函数（115）消去设值函数。如果可能的话，把字段声明为不可变。

测试。

范例

我有一个很简单的 Person 类。

class Person…
get name() {return this._name;}
set name(arg) {this._name = arg;}
get id() {return this._id;}
set id(arg) {this._id = arg;}

目前我会这样创建新对象：

const martin = new Person();
martin.name = "martin";
martin.id = "1234";

对象创建之后，name 字段可能会改变，但 id 字段不会。为了更清晰地表达这个设计意图，我希望移除对应 id 字段的设值函数。

但 id 字段还得设置初始值，所以我首先用改变函数声明（124）在构造函数中添加对应的参数。

class Person…
constructor(id) {
  this.id = id;
}

然后调整创建脚本，改为从构造函数设值 id 字段值。

const martin = new Person("1234");
martin.name = "martin";
martin.id = "1234";

所有创建 Person 对象的地方都要如此修改，每次修改之后要执行测试。

全部修改完成后，就可以用内联函数（115）消去设值函数。

class Person…
constructor(id) {
  this._id = id;
}
get name() {return this._name;}
set name(arg) {this._name = arg;}
get id() {return this._id;}
set id(arg) {this._id = arg;}

11.8 以工厂函数取代构造函数（Replace Constructor with Factory Function）

曾用名：以工厂函数取代构造函数（Replace Constructor with Factory Method）

leadEngineer = new Employee(document.leadEngineer, "E");

leadEngineer = createEngineer(document.leadEngineer);

动机

很多面向对象语言都有特别的构造函数，专门用于对象的初始化。需要新建一个对象时，客户端通常会调用构造函数。但与一般的函数相比，构造函数又常有一些丑陋的局限性。例如，Java 的构造函数只能返回当前所调用类的实例，也就是说，我无法根据环境或参数信息返回子类实例或代理对象；构造函数的名字是固定的，因此无法使用比默认名字更清晰的函数名；构造函数需要通过特殊的操作符来调用（在很多语言中是 new 关键字），所以在要求普通函数的场合就难以使用。

工厂函数就不受这些限制。工厂函数的实现内部可以调用构造函数，但也可以换成别的方式实现。

做法

新建一个工厂函数，让它调用现有的构造函数。

将调用构造函数的代码改为调用工厂函数。

每修改一处，就执行测试。

尽量缩小构造函数的可见范围。

范例

又是那个单调乏味的例子：员工薪资系统。我还是以 Employee 类表示“员工”。

class Employee…
constructor (name, typeCode) {
  this._name = name;
  this._typeCode = typeCode;
}
get name() {return this._name;}
get type() {
  return Employee.legalTypeCodes[this._typeCode];
}
static get legalTypeCodes() {
  return {"E": "Engineer", "M": "Manager", "S": "Salesman"};
}

使用它的代码有这样的：

调用方…
candidate = new Employee(document.name, document.empType);

也有这样的：

调用方…
const leadEngineer = new Employee(document.leadEngineer, "E");

重构的第一步是创建工厂函数，其中把对象创建的责任直接委派给构造函数。

顶层作用域…
function createEmployee(name, typeCode) {
  return new Employee(name, typeCode);
}

然后找到构造函数的调用者，并逐一修改它们，令其使用工厂函数。

第一处的修改很简单。

调用方…
candidate = createEmployee(document.name, document.empType);

第二处则可以这样使用工厂函数。

调用方…
const leadEngineer = createEmployee(document.leadEngineer, "E");

但我不喜欢这里的类型码——以字符串字面量的形式传入类型码，一般来说都是坏味道。所以我更愿意再新建一个工厂函数，把“员工类别”的信息嵌在函数名里体现。

调用方…
const leadEngineer = createEngineer(document.leadEngineer);
顶层作用域…
function createEngineer(name) {
  return new Employee(name, "E");
}

11.9 以命令取代函数（Replace Function with Command）

曾用名：以函数对象取代函数（Replace Method with Method Object）

反向重构：以函数取代命令（344）

function score(candidate, medicalExam, scoringGuide) {
  let result = 0;
  let healthLevel = 0;
  // long body code
}

class Scorer {
  constructor(candidate, medicalExam, scoringGuide) {
    this._candidate = candidate;
    this._medicalExam = medicalExam;
    this._scoringGuide = scoringGuide;
  }

  execute() {
    this._result = 0;
    this._healthLevel = 0;
    // long body code
  }
}

动机

函数，不管是独立函数，还是以方法（method）形式附着在对象上的函数，是程序设计的基本构造块。不过，将函数封装成自己的对象，有时也是一种有用的办法。这样的对象我称之为“命令对象”（command object），或者简称“命令”（command）。这种对象大多只服务于单一函数，获得对该函数的请求，执行该函数，就是这种对象存在的意义。

与普通的函数相比，命令对象提供了更大的控制灵活性和更强的表达能力。除了函数调用本身，命令对象还可以支持附加的操作，例如撤销操作。我可以通过命令对象提供的方法来设值命令的参数值，从而支持更丰富的生命周期管理能力。我可以借助继承和钩子对函数行为加以定制。如果我所使用的编程语言支持对象但不支持函数作为一等公民，通过命令对象就可以给函数提供大部分相当于一等公民的能力。同样，即便编程语言本身并不支持嵌套函数，我也可以借助命令对象的方法和字段把复杂的函数拆解开，而且在测试和调试过程中可以直接调用这些方法。

所有这些都是使用命令对象的好理由，所以我要做好准备，一旦有需要，就能把函数重构成命令。不过我们不能忘记，命令对象的灵活性也是以复杂性作为代价的。所以，如果要在作为一等公民的函数和命令对象之间做个选择，95%的时候我都会选函数。只有当我特别需要命令对象提供的某种能力而普通的函数无法提供这种能力时，我才会考虑使用命令对象。

跟软件开发中的很多词汇一样，“命令”这个词承载了太多含义。在这里，“命令”是指一个对象，其中封装了一个函数调用请求。这是遵循《设计模式》[gof]一书中的命令模式（command pattern）。在这个意义上，使用“命令”一词时，我会先用完整的“命令对象”一词设定上下文，然后视情况使用简略的“命令”一词。在命令与查询分离原则（command-query separation principle）中也用到了“命令”一词，此时“命令”是一个对象所拥有的函数，调用该函数可以改变对象可观察的状态。我尽量避免使用这个意义上的“命令”一词，而更愿意称其为“修改函数”（modifier）或者“改变函数”（mutator）。

做法

为想要包装的函数创建一个空的类，根据该函数的名字为其命名。

使用搬移函数（198）把函数移到空的类里。

保持原来的函数作为转发函数，至少保留到重构结束之前才删除。

遵循编程语言的命名规范来给命令对象起名。如果没有合适的命名规范，就给命令对象中负责实际执行命令的函数起一个通用的名字，例如“execute”或者“call”。

可以考虑给每个参数创建一个字段，并在构造函数中添加对应的参数。

范例

JavaScript 语言有很多缺点，但把函数作为一等公民对待，是它最正确的设计决策之一。在不具备这种能力的编程语言中，我经常要费力为很常见的任务创建命令对象，JavaScript 则省去了这些麻烦。不过，即便在 JavaScript 中，有时也需要用到命令对象。

一个典型的应用场景就是拆解复杂的函数，以便我理解和修改。要想真正展示这个重构手法的价值，我需要一个长而复杂的函数，但这写起来太费事，你读起来也麻烦。所以我在这里展示的函数其实很短，并不真的需要本重构手法，还望读者权且包涵。下面的函数用于给一份保险申请评分。

function score(candidate, medicalExam, scoringGuide) {
  let result = 0;
  let healthLevel = 0;
  let highMedicalRiskFlag = false;

  if (medicalExam.isSmoker) {
    healthLevel += 10;
    highMedicalRiskFlag = true;
  }
  let certificationGrade = "regular";
  if (scoringGuide.stateWithLowCertification(candidate.originState)) {
    certificationGrade = "low";
    result -= 5;
  } // lots more code like this
  result -= Math.max(healthLevel - 5, 0);
  return result;
}

我首先创建一个空的类，用搬移函数（198）把上述函数搬到这个类里去。

function score(candidate, medicalExam, scoringGuide) {
  return new Scorer().execute(candidate, medicalExam, scoringGuide);
}

class Scorer {
  execute(candidate, medicalExam, scoringGuide) {
    let result = 0;
    let healthLevel = 0;
    let highMedicalRiskFlag = false;

    if (medicalExam.isSmoker) {
      healthLevel += 10;
      highMedicalRiskFlag = true;
    }
    let certificationGrade = "regular";
    if (scoringGuide.stateWithLowCertification(candidate.originState)) {
      certificationGrade = "low";
      result -= 5;
    } // lots more code like this
    result -= Math.max(healthLevel - 5, 0);
    return result;
  }
}

大多数时候，我更愿意在命令对象的构造函数中传入参数，而不让 execute 函数接收参数。在这样一个简单的拆解场景中，这一点带来的影响不大；但如果我要处理的命令需要更复杂的参数设置周期或者大量定制，上述做法就会带来很多便利：多个命令类可以分别从各自的构造函数中获得各自不同的参数，然后又可以排成队列挨个执行，因为它们的 execute 函数签名都一样。

我可以每次搬移一个参数到构造函数。

function score(candidate, medicalExam, scoringGuide) {
  return new Scorer(candidate).execute(candidate, medicalExam, scoringGuide);
}
class Scorer…
constructor(candidate){
 this._candidate = candidate;
}

execute (candidate, medicalExam, scoringGuide) {
 let result = 0;
 let healthLevel = 0;
 let highMedicalRiskFlag = false;

 if (medicalExam.isSmoker) {
  healthLevel += 10;
  highMedicalRiskFlag = true;
 }
 let certificationGrade = "regular";
 if (scoringGuide.stateWithLowCertification(this._candidate.originState)) {
  certificationGrade = "low";
  result -= 5;
 }
 // lots more code like this
 result -= Math.max(healthLevel - 5, 0);
 return result;
}

继续处理其他参数：

function score(candidate, medicalExam, scoringGuide) {
  return new Scorer(candidate, medicalExam, scoringGuide).execute();
}
class Scorer…
constructor(candidate, medicalExam, scoringGuide){
 this._candidate = candidate;
 this._medicalExam = medicalExam;
 this._scoringGuide = scoringGuide;
}
execute () {
 let result = 0;
 let healthLevel = 0;
 let highMedicalRiskFlag = false;

 if (this._medicalExam.isSmoker) {
  healthLevel += 10;
  highMedicalRiskFlag = true;
 }
 let certificationGrade = "regular";
 if (this._scoringGuide.stateWithLowCertification(this._candidate.originState)) {
  certificationGrade = "low";
  result -= 5;
 }
 // lots more code like this
 result -= Math.max(healthLevel - 5, 0);
 return result;
}

以命令取代函数的重构到此就结束了，不过之所以要做这个重构，是为了拆解复杂的函数，所以我还是大致展示一下如何拆解。下一步是把所有局部变量都变成字段，我还是每次修改一处。

class Scorer…
constructor(candidate, medicalExam, scoringGuide){
 this._candidate = candidate;
 this._medicalExam = medicalExam;
 this._scoringGuide = scoringGuide;
}

execute () {
 this._result = 0;
 let healthLevel = 0;
 let highMedicalRiskFlag = false;

 if (this._medicalExam.isSmoker) {
  healthLevel += 10;
  highMedicalRiskFlag = true;
 }
 let certificationGrade = "regular";
 if (this._scoringGuide.stateWithLowCertification(this._candidate.originState)) {
  certificationGrade = "low";
  this._result -= 5;
 }
 // lots more code like this
 this._result -= Math.max(healthLevel - 5, 0);
 return this._result;
}

重复上述过程，直到所有局部变量都变成字段。（“把局部变量变成字段”这个重构手法是如此简单，以至于我都没有在重构名录中给它一席之地。对此我略感愧疚。）

class Scorer…
constructor(candidate, medicalExam, scoringGuide){
 this._candidate = candidate;
 this._medicalExam = medicalExam;
 this._scoringGuide = scoringGuide;
}

execute () {
 this._result = 0;
 this._healthLevel = 0;
 this._highMedicalRiskFlag = false;

 if (this._medicalExam.isSmoker) {
  this._healthLevel += 10;
  this._highMedicalRiskFlag = true;
 }
 this._certificationGrade = "regular";
 if (this._scoringGuide.stateWithLowCertification(this._candidate.originState)) {
  this._certificationGrade = "low";
  this._result -= 5;
 }
 // lots more code like this
 this._result -= Math.max(this._healthLevel - 5, 0);
 return this._result;
}

现在函数的所有状态都已经移到了命令对象中，我可以放心使用提炼函数（106）等重构手法，而不用纠结于局部变量的作用域之类问题。

class Scorer…
execute () {
 this._result = 0;
 this._healthLevel = 0;
 this._highMedicalRiskFlag = false;

 this.scoreSmoking();
 this._certificationGrade = "regular";
 if (this._scoringGuide.stateWithLowCertification(this._candidate.originState)) {
  this._certificationGrade = "low";
  this._result -= 5;
 }
 // lots more code like this
 this._result -= Math.max(this._healthLevel - 5, 0);
 return this._result;
 }
scoreSmoking() {
 if (this._medicalExam.isSmoker) {
  this._healthLevel += 10;
  this._highMedicalRiskFlag = true;
 }
}

这样我就可以像处理嵌套函数一样处理命令对象。实际上，在 JavaScript 中运用此重构手法时，的确可以考虑用嵌套函数来代替命令对象。不过我还是会使用命令对象，不仅因为我对命令对象更熟悉，而且还因为我可以针对命令对象中任何一个函数进行测试和调试。

11.10 以函数取代命令（Replace Command with Function）

反向重构：以命令取代函数（337）

class ChargeCalculator {
  constructor(customer, usage) {
    this._customer = customer;
    this._usage = usage;
  }
  execute() {
    return this._customer.rate * this._usage;
  }
}

function charge(customer, usage) {
  return customer.rate * usage;
}

动机

命令对象为处理复杂计算提供了强大的机制。借助命令对象，可以轻松地将原本复杂的函数拆解为多个方法，彼此之间通过字段共享状态；拆解后的方法可以分别调用；开始调用之前的数据状态也可以逐步构建。但这种强大是有代价的。大多数时候，我只是想调用一个函数，让它完成自己的工作就好。如果这个函数不是太复杂，那么命令对象可能显得费而不惠，我就应该考虑将其变回普通的函数。

做法

运用提炼函数（106），把“创建并执行命令对象”的代码单独提炼到一个函数中。

这一步会新建一个函数，最终这个函数会取代现在的命令对象。

对命令对象在执行阶段用到的函数，逐一使用内联函数（115）。

如果被调用的函数有返回值，请先对调用处使用提炼变量（119），然后再使用内联函数（115）。

使用改变函数声明（124），把构造函数的参数转移到执行函数。

对于所有的字段，在执行函数中找到引用它们的地方，并改为使用参数。每次修改后都要测试。

把“调用构造函数”和“调用执行函数”两步都内联到调用方（也就是最终要替换命令对象的那个函数）。

测试。

用移除死代码（237）把命令类消去。

范例

假设我有一个很小的命令对象。

class ChargeCalculator {
  constructor(customer, usage, provider) {
    this._customer = customer;
    this._usage = usage;
    this._provider = provider;
  }
  get baseCharge() {
    return this._customer.baseRate * this._usage;
  }
  get charge() {
    return this.baseCharge + this._provider.connectionCharge;
  }
}

使用方的代码如下。

调用方…
monthCharge = new ChargeCalculator(customer, usage, provider).charge;

命令类足够小、足够简单，变成函数更合适。

首先，我用提炼函数（106）把命令对象的创建与调用过程包装到一个函数中。

调用方…
monthCharge = charge(customer, usage, provider);
顶层作用域…
function charge(customer, usage, provider) {
  return new ChargeCalculator(customer, usage, provider).charge;
}

接下来要考虑如何处理支持函数（也就是这里的 baseCharge 函数）。对于有返回值的函数，我一般会先用提炼变量（119）把返回值提炼出来。

class ChargeCalculator…
get baseCharge() {
  return this._customer.baseRate * this._usage;
}
get charge() {
  const baseCharge = this.baseCharge;
  return baseCharge + this._provider.connectionCharge;
}

然后对支持函数使用内联函数（115）。

class ChargeCalculator…
get charge() {
  const baseCharge = this._customer.baseRate * this._usage;
  return baseCharge + this._provider.connectionCharge;
}

现在所有逻辑处理都集中到一个函数了，下一步是把构造函数传入的数据移到主函数。首先用改变函数声明（124）把构造函数的参数逐一添加到 charge 函数上。

class ChargeCalculator…
constructor (customer, usage, provider){
 this._customer = customer;
 this._usage = usage;
 this._provider = provider;
}

charge(customer, usage, provider) {
 const baseCharge = this._customer.baseRate * this._usage;
 return baseCharge + this._provider.connectionCharge;
}
顶层作用域…
function charge(customer, usage, provider) {
  return new ChargeCalculator(customer, usage, provider).charge(
    customer,
    usage,
    provider
  );
}

然后修改 charge 函数的实现，改为使用传入的参数。这个修改可以小步进行，每次使用一个参数。

class ChargeCalculator…
constructor (customer, usage, provider){
 this._customer = customer;
 this._usage = usage;
 this._provider = provider;
}

charge(customer, usage, provider) {
 const baseCharge = customer.baseRate * this._usage;
 return baseCharge + this._provider.connectionCharge;
}

构造函数中对 this._customer 字段的赋值不删除也没关系，因为反正没人使用这个字段。但我更愿意去掉这条赋值语句，因为去掉它以后，如果在函数实现中漏掉了一处对字段的使用没有修改，测试就会失败。（如果我真的犯了这个错误而测试没有失败，我就应该考虑增加测试了。）

其他参数也如法炮制，直到 charge 函数不再使用任何字段：

class ChargeCalculator…
charge(customer, usage, provider) {
  const baseCharge = customer.baseRate * usage;
  return baseCharge + provider.connectionCharge;
}

现在我就可以把所有逻辑都内联到顶层的 charge 函数中。这是内联函数（115）的一种特殊情况，我需要把构造函数和执行函数一并内联。

顶层作用域…
function charge(customer, usage, provider) {
  const baseCharge = customer.baseRate * usage;
  return baseCharge + provider.connectionCharge;
}

现在命令类已经是死代码了，可以用移除死代码（237）给它一个体面的葬礼。

第 12 章 处理继承关系

在最后一章里，我将介绍面向对象编程技术里最为人熟知的一个特性：继承。与任何强有力的特性一样，继承机制十分实用，却也经常被误用，而且常得等你用上一段时间，遇见了痛点，才能察觉误用所在。

特性（主要是函数和字段）经常需要在继承体系里上下调整。我有一组手法专门用来处理此类调整：函数上移（350）、字段上移（353）、构造函数本体上移（355）、函数下移（359）以及字段下移（361）。我可以使用提炼超类（375）、移除子类（369）以及折叠继承体系（380）来为继承体系添加新类或删除旧类。如果一个字段仅仅作为类型码使用，根据其值来触发不同的行为，那么我会通过以子类取代类型码（362），用一个子类来取代这样的字段。

继承本身是一个强有力的工具，但有时它也可能被用于错误的地方，有时本来适合使用继承的场景变得不再合适——若果真如此，我就会用以委托取代子类（381）或以委托取代超类（399）将继承体系转化成委托调用。

12.1 函数上移（Pull Up Method）

反向重构：函数下移（359）

class Employee {...}

class Salesman extends Employee {
 get name() {...}
}

class Engineer extends Employee {
 get name() {...}
}


class Employee {
 get name() {...}
}

class Salesman extends Employee {...}
class Engineer extends Employee {...}

动机

避免重复代码是很重要的。重复的两个函数现在也许能够正常工作，但假以时日却只会成为滋生 bug 的温床。无论何时，只要系统内出现重复，你就会面临“修改其中一个却未能修改另一个”的风险。通常，找出重复也有一定的难度。

如果某个函数在各个子类中的函数体都相同（它们很可能是通过复制粘贴得到的），这就是最显而易见的函数上移适用场合。当然，情况并不总是如此明显。我也可以只管放心地重构，再看看测试程序会不会发牢骚，但这就需要对我的测试有充分的信心。我发现，观察这些可能重复的函数之间的差异往往大有收获：它们经常会向我展示那些我忘记测试的行为。

函数上移常常紧随其他重构而被使用。也许我能找出若干个身处不同子类内的函数，而它们又可以通过某种形式的参数调整成为相同的函数。这时候，最简单的办法就是先分别对这些函数应用函数参数化（310），然后应用函数上移。

函数上移过程中最麻烦的一点就是，被提升的函数可能会引用只出现于子类而不出现于超类的特性。此时，我就得用字段上移（353）和函数上移先将这些特性（类或者函数）提升到超类。

如果两个函数工作流程大体相似，但实现细节略有差异，那么我会考虑先借助塑造模板函数（Form Template Method）[mf-ft]构造出相同的函数，然后再提升它们。

做法

检查待提升函数，确定它们是完全一致的。

如果它们做了相同的事情，但函数体并不完全一致，那就先对它们进行重构，直到其函数体完全一致。

检查函数体内引用的所有函数调用和字段都能从超类中调用到。

如果待提升函数的签名不同，使用改变函数声明（124）将那些签名都修改为你想要在超类中使用的签名。

在超类中新建一个函数，将某一个待提升函数的代码复制到其中。

执行静态检查。

移除一个待提升的子类函数。

测试。

逐一移除待提升的子类函数，直到只剩下超类中的函数为止。

范例

我手上有两个子类，它们之中各有一个函数做了相同的事情：

class Employee extends Party…
get annualCost() {
  return this.monthlyCost * 12;
}
class Department extends Party…
get totalAnnualCost() {
  return this.monthlyCost * 12;
}

检查两个类的函数时我发现，两个函数都引用了 monthlyCost 属性，但后者并未在超类中定义，而是在两个子类中各自定义了一份实现。因为 JavaScript 是动态语言，这样做没有问题；但如果是在一门静态语言里，我就必须将 monthlyCost 声明为 Party 类上的抽象函数，否则编译器就会报错。

两个函数各有不同的名字，因此第一步是用改变函数声明（124）统一它们的函数名。

class Department…
get annualCost() {
  return this.monthlyCost * 12;
}

然后，我从其中一个子类中将 annualCost 函数复制到超类。

class Party…
get annualCost() {
  return this.monthlyCost * 12;
}

在静态语言里，做完这一步我就可以编译一次，确保超类函数的所有引用都能正常工作。但这是在 JavaScript 里，编译显然帮不上什么忙，因此我直接先从 Employee 中移除 annualCost 函数，测试，接着移除 Department 类中的 annualCost 函数。

这项重构手法至此即告完成，但还有一个遗留问题需要解决：annualCost 函数中调用了 monthlyCost，但后者并未在 Party 类中显式声明。当然代码仍能正常工作，这得益于 JavaScript 是动态语言，它能自动帮你调用子类上的同名函数。但若能明确传达出“继承 Party 类的子类需要提供一个 monthlyCost 实现”这个信息，无疑也有很大的价值，特别是对日后需要添加子类的后来者。其中一种好的传达方式是添加一个如下的陷阱（trap）函数。

class Party…
get monthlyCost() {
  throw new SubclassResponsibilityError();
}

我称上述抛出的错误为一个“子类未履行职责错误”，这是从 Smalltalk 借鉴来的名字。

12.2 字段上移（Pull Up Field）

反向重构：字段下移（361）

class Employee {...} // Java

class Salesman extends Employee {
 private String name;
}

class Engineer extends Employee {
 private String name;
}


class Employee {
 protected String name;
}

class Salesman extends Employee {...}
class Engineer extends Employee {...}

动机

如果各子类是分别开发的，或者是在重构过程中组合起来的，你常会发现它们拥有重复特性，特别是字段更容易重复。这样的字段有时拥有近似的名字，但也并非绝对如此。判断若干字段是否重复，唯一的办法就是观察函数如何使用它们。如果它们被使用的方式很相似，我就可以将它们提升到超类中去。

本项重构可从两方面减少重复：首先它去除了重复的数据声明；其次它使我可以将使用该字段的行为从子类移至超类，从而去除重复的行为。

许多动态语言不需要在类定义中定义字段，相反，字段是在第一次被赋值的同时完成声明。在这种情况下，字段上移基本上是应用构造函数本体上移（355）后的必然结果。

做法

针对待提升之字段，检查它们的所有使用点，确认它们以同样的方式被使用。

如果这些字段的名称不同，先使用变量改名（137）为它们取个相同的名字。

在超类中新建一个字段。

新字段需要对所有子类可见（在大多数语言中 protected 权限便已足够）。

移除子类中的字段。

测试。

12.3 构造函数本体上移（Pull Up Constructor Body）

class Party {...}

class Employee extends Party {
 constructor(name, id, monthlyCost) {
  super();
  this._id = id;
  this._name = name;
  this._monthlyCost = monthlyCost;
 }
}


class Party {
 constructor(name){
  this._name = name;
 }
}

class Employee extends Party {
 constructor(name, id, monthlyCost) {
  super(name);
  this._id = id;
  this._monthlyCost = monthlyCost;
 }
}

动机

构造函数是很奇妙的东西。它们不是普通函数，使用它们比使用普通函数受到更多的限制。

如果我看见各个子类中的函数有共同行为，我的第一个念头就是使用提炼函数（106）将它们提炼到一个独立函数中，然后使用函数上移（350）将这个函数提升至超类。但构造函数的出现打乱了我的算盘，因为它们附加了特殊的规则，对一些做法与函数的调用次序有所限制。要对付它们，我需要略微不同的做法。

如果重构过程过于复杂，我会考虑转而使用以工厂函数取代构造函数（334）。

做法

如果超类还不存在构造函数，首先为其定义一个。确保让子类调用超类的构造函数。

使用移动语句（223）将子类中构造函数中的公共语句移动到超类的构造函数调用语句之后。

逐一移除子类间的公共代码，将其提升至超类构造函数中。对于公共代码中引用到的变量，将其作为参数传递给超类的构造函数。

测试。

如果存在无法简单提升至超类的公共代码，先应用提炼函数（106），再利用函数上移（350）提升之。

范例

我以下列“雇员”的例子开始：

class Party {}

class Employee extends Party {
 constructor(name, id, monthlyCost) {
  super();
  this._id = id;
  this._name = name;
  this._monthlyCost = monthlyCost;
 }
 // rest of class...
class Department extends Party {
 constructor(name, staff){
  super();
  this._name = name;
  this._staff = staff;
 }
 // rest of class...

Party 的两个子类间存在公共代码，也即是对名字（name）的赋值。我先用移动语句（223）将 Employee 中的这行赋值语句移动到 super()调用后面：

class Employee extends Party {
  constructor(name, id, monthlyCost) {
    super();
    this._name = name;
    this._id = id;
    this._monthlyCost = monthlyCost;
  }
  // rest of class...

测试。之后我将这行公共代码提升至超类的构造函数中。由于其中引用了一个子类构造函数传入的参数 name，于是我将该参数一并传给超类构造函数。

class Party…
constructor(name){
  this._name = name;
}
class Employee…
constructor(name, id, monthlyCost) {
  super(name);
  this._id = id;
  this._monthlyCost = monthlyCost;
}
class Department…
constructor(name, staff){
  super(name);
  this._staff = staff;
}

运行测试。然后大功告成。

多数时候，一个构造函数的工作原理都是这样：先（通过 super 调用）初始化共用的数据，再由各个子类完成额外的工作。但是，偶尔也需要将共用行为的初始化提升至超类，这时问题便来了。

请看下面的例子。

class Employee…
constructor (name) {...}

get isPrivileged() {...}

assignCar() {...}
class Manager extends Employee…
constructor(name, grade) {
  super(name);
  this._grade = grade;
  if (this.isPrivileged) this.assignCar(); // every subclass does this
}

get isPrivileged() {
  return this._grade >4;
}

这里我无法简单地提升 isPrivileged 函数至超类，因为调用它之前需要先为 grade 字段赋值，而该字段只能在子类的构造函数中初始化。

在这种场景下，我可以对这部分公共代码使用提炼函数（106）。

class Manager…
constructor(name, grade) {
  super(name);
  this._grade = grade;
  this.finishConstruction();
}

finishConstruction() {
  if (this.isPrivileged) this.assignCar();
}

然后再使用函数上移（350）将提炼得到的函数提升至超类。

class Employee…
finishConstruction() {
  if (this.isPrivileged) this.assignCar();
}

12.4 函数下移（Push Down Method）

反向重构：函数上移（350）

class Employee {
  get quota {...}
}

class Engineer extends Employee {...}
class Salesman extends Employee {...}


class Employee {...}
class Engineer extends Employee {...}
class Salesman extends Employee {
  get quota {...}
}

动机

如果超类中的某个函数只与一个（或少数几个）子类有关，那么最好将其从超类中挪走，放到真正关心它的子类中去。这项重构手法只有在超类明确知道哪些子类需要这个函数时适用。如果超类不知晓这个信息，那我就得用以多态取代条件表达式（272），只留些共用的行为在超类。

做法

将超类中的函数本体复制到每一个需要此函数的子类中。

删除超类中的函数。

测试。

将该函数从所有不需要它的那些子类中删除。

测试。

12.5 字段下移（Push Down Field）

反向重构：字段上移（353）

class Employee {   // Java
 private String quota;
}

class Engineer extends Employee {...}
class Salesman extends Employee {...}


class Employee {...}
class Engineer extends Employee {...}

class Salesman extends Employee {
 protected String quota;
}

动机

如果某个字段只被一个子类（或者一小部分子类）用到，就将其搬移到需要该字段的子类中。

做法

在所有需要该字段的子类中声明该字段。

将该字段从超类中移除。

测试。

将该字段从所有不需要它的那些子类中删掉。

测试。

12.6 以子类取代类型码（Replace Type Code with Subclasses）

包含旧重构：以 State/Strategy 取代类型码（Replace Type Code with State/Strategy）

包含旧重构：提炼子类（Extract Subclass）

反向重构：移除子类（369）

function createEmployee(name, type) {
  return new Employee(name, type);
}


function createEmployee(name, type) {
  switch (type) {
    case "engineer": return new Engineer(name);
    case "salesman": return new Salesman(name);
    case "manager": return new Manager (name);
}

动机

软件系统经常需要表现“相似但又不同的东西”，比如员工可以按职位分类（工程师、经理、销售），订单可以按优先级分类（加急、常规）。表现分类关系的第一种工具是类型码字段——根据具体的编程语言，可能实现为枚举、符号、字符串或者数字。类型码的取值经常来自给系统提供数据的外部服务。

大多数时候，有这样的类型码就够了。但也有些时候，我可以再多往前一步，引入子类。继承有两个诱人之处。首先，你可以用多态来处理条件逻辑。如果有几个函数都在根据类型码的取值采取不同的行为，多态就显得特别有用。引入子类之后，我可以用以多态取代条件表达式（272）来处理这些函数。

另外，有些字段或函数只对特定的类型码取值才有意义，例如“销售目标”只对“销售”这类员工才有意义。此时我可以创建子类，然后用字段下移（361）把这样的字段放到合适的子类中去。当然，我也可以加入验证逻辑，确保只有当类型码取值正确时才使用该字段，不过子类的形式能更明确地表达数据与类型之间的关系。

在使用以子类取代类型码时，我需要考虑一个问题：应该直接处理携带类型码的这个类，还是应该处理类型码本身呢？以前面的例子来说，我是应该让“工程师”成为“员工”的子类，还是应该在“员工”类包含“员工类别”属性、从后者继承出“工程师”和“经理”等子类型呢？直接的子类继承（前一种方案）比较简单，但职位类别就不能用在其他场合了。另外，如果员工的类别是可变的，那么也不能使用直接继承的方案。如果想在“员工类别”之下创建子类，可以运用以对象取代基本类型（174）把类型码包装成“员工类别”类，然后对其使用以子类取代类型码（362）。

做法

自封装类型码字段。

任选一个类型码取值，为其创建一个子类。覆写类型码类的取值函数，令其返回该类型码的字面量值。

创建一个选择器逻辑，把类型码参数映射到新的子类。

如果选择直接继承的方案，就用以工厂函数取代构造函数（334）包装构造函数，把选择器逻辑放在工厂函数里；如果选择间接继承的方案，选择器逻辑可以保留在构造函数里。

测试。

针对每个类型码取值，重复上述“创建子类、添加选择器逻辑”的过程。每次修改后执行测试。

去除类型码字段。

测试。

使用函数下移（359）和以多态取代条件表达式（272）处理原本访问了类型码的函数。全部处理完后，就可以移除类型码的访问函数。

范例

这个员工管理系统的例子已经被用烂了……

class Employee…
constructor(name, type){
  this.validateType(type);
  this._name = name;
  this._type = type;
}
validateType(arg) {
  if (!["engineer", "manager", "salesman"].includes(arg))
    throw new Error(`Employee cannot be of type ${arg}`);
}
toString() {return `${this._name} (${this._type})`;}

第一步是用封装变量（132）将类型码自封装起来。

class Employee…
get type() {return this._type;}
toString() {return `${this._name} (${this.type})`;}

请注意，toString 函数的实现中去掉了 this._type 的下划线，改用新建的取值函数了。

我选择从工程师（“engineer”）这个类型码开始重构。我打算采用直接继承的方案，也就是继承 Employee 类。子类很简单，只要覆写类型码的取值函数，返回适当的字面量值就行了。

class Engineer extends Employee {
  get type() {
    return "engineer";
  }
}

虽然 JavaScript 的构造函数也可以返回其他对象，但如果把选择器逻辑放在这儿，它会与字段初始化逻辑相互纠缠，搞得一团混乱。所以我会先运用以工厂函数取代构造函数（334），新建一个工厂函数以便安放选择器逻辑。

function createEmployee(name, type) {
  return new Employee(name, type);
}

然后我把选择器逻辑放在工厂函数中，从而开始使用新的子类。

function createEmployee(name, type) {
  switch (type) {
    case "engineer":
      return new Engineer(name, type);
  }
  return new Employee(name, type);
}

测试，确保一切运转正常。不过由于我的偏执，我随后会修改 Engineer 类中覆写的 type 函数，让它返回另外一个值，再次执行测试，确保会有测试失败，这样我才能肯定：新建的子类真的被用到了。然后我把 type 函数的返回值改回正确的状态，继续处理别的类型。我一次处理一个类型，每次修改后都执行测试。

class Salesman extends Employee {
  get type() {
    return "salesman";
  }
}

class Manager extends Employee {
  get type() {
    return "manager";
  }
}

function createEmployee(name, type) {
  switch (type) {
    case "engineer":
      return new Engineer(name, type);
    case "salesman":
      return new Salesman(name, type);
    case "manager":
      return new Manager(name, type);
  }
  return new Employee(name, type);
}

全部修改完成后，我就可以去掉类型码字段及其在超类中的取值函数（子类中的取值函数仍然保留）。

class Employee…
constructor(name, type){
 this.validateType(type);
 this._name = name;
 this._type = type;
}

get type() {return this._type;}
toString() {return `${this._name} (${this.type})`;}

测试，确保一切工作正常，我就可以移除验证逻辑，因为分发逻辑做的是同一回事。

class Employee…
constructor(name, type){
 this.validateType(type);
 this._name = name;
}
function createEmployee(name, type) {
 switch (type) {
  case "engineer": return new Engineer(name, type);
  case "salesman": return new Salesman(name, type);
  case "manager":  return new Manager (name, type);
  default: throw new Error(`Employee cannot be of type ${type}`);
 }
 return new Employee(name, type);
}

现在，构造函数的类型参数已经没用了，用改变函数声明（124）把它干掉。

class Employee…
constructor(name, type){
 this._name = name;
}

function createEmployee(name, type) {
 switch (type) {
  case "engineer": return new Engineer(name, type);
  case "salesman": return new Salesman(name, type);
  case "manager": return new Manager (name, type);
  default: throw new Error(`Employee cannot be of type ${type}`);
 }
}

子类中获取类型码的访问函数——get type 函数——仍然留着。通常我会希望把这些函数也干掉，不过可能需要多花点儿时间，因为有其他函数使用了它们。我会用以多态取代条件表达式（272）和函数下移（359）来处理这些访问函数。到某个时候，已经没有代码使用类型码的访问函数了，我再用移除死代码（237）给它们送终。

范例：使用间接继承

还是前面这个例子，我们回到最起初的状态，不过这次我已经有了“全职员工”和“兼职员工”两个子类，所以不能再根据员工类别代码创建子类了。另外，我可能需要允许员工类别动态调整，这也会导致不能使用直接继承的方案。

class Employee…
constructor(name, type){
 this.validateType(type);
 this._name = name;
 this._type = type;
}
validateType(arg) {
 if (!["engineer", "manager", "salesman"].includes(arg))
  throw new Error(`Employee cannot be of type ${arg}`);
}
get type()    {return this._type;}
set type(arg) {this._type = arg;}

get capitalizedType() {
 return this._type.charAt(0).toUpperCase() + this._type.substr(1).toLowerCase();
}
toString() {
 return `${this._name} (${this.capitalizedType})`;
}

这次的 toString 函数要更复杂一点，以便稍后展示用。

首先，我用以对象取代基本类型（174）包装类型码。

class EmployeeType {
  constructor(aString) {
    this._value = aString;
  }
  toString() {
    return this._value;
  }
}
class Employee…
constructor(name, type){
 this.validateType(type);
 this._name = name;
 this.type = type;
}
validateType(arg) {
 if (!["engineer", "manager", "salesman"].includes(arg))
  throw new Error(`Employee cannot be of type ${arg}`);
}
get typeString()  {return this._type.toString();}
get type()    {return this._type;}
set type(arg) {this._type = new EmployeeType(arg);}

get capitalizedType() {
 return this.typeString.charAt(0).toUpperCase()
  + this.typeString.substr(1).toLowerCase();
}
toString() {
 return `${this._name} (${this.capitalizedType})`;
}

然后使用以子类取代类型码（362）的老套路，把员工类别代码变成子类。

class Employee…
set type(arg) {this._type = Employee.createEmployeeType(arg);}

 static createEmployeeType(aString) {
  switch(aString) {
   case "engineer": return new Engineer();
   case "manager":  return new Manager ();
   case "salesman": return new Salesman();
   default: throw new Error(`Employee cannot be of type ${aString}`);
  }
 }

class EmployeeType {
}
class Engineer extends EmployeeType {
 toString() {return "engineer";}
}
class Manager extends EmployeeType {
 toString() {return "manager";}
}
class Salesman extends EmployeeType {
 toString() {return "salesman";}
}

如果重构到此为止的话，空的 EmployeeType 类可以去掉。但我更愿意留着它，用来明确表达各个子类之间的关系。并且有一个超类，也方便把其他行为搬移进去，例如我专门放在 toString 函数里的“名字大写”逻辑，就可以搬到超类。

class Employee…
toString() {
  return `${this._name} (${this.type.capitalizedName})`;
}
class EmployeeType…
get capitalizedName() {
return this.toString().charAt(0).toUpperCase()
  + this.toString().substr(1).toLowerCase();
}

熟悉本书第 1 版的读者大概能看出，这个例子来自第 1 版的以 State/Strategy 取代类型码重构手法。现在我认为这是以间接继承的方式使用以子类取代类型码，所以就不再将其作为一个单独的重构手法了。（而且我也一直不喜欢那个老重构手法的名字。）

12.7 移除子类（Remove Subclass）

曾用名：以字段取代子类（Replace Subclass with Fields）

反向重构：以子类取代类型码（362）

class Person {
  get genderCode() {
    return "X";
  }
}
class Male extends Person {
  get genderCode() {
    return "M";
  }
}
class Female extends Person {
  get genderCode() {
    return "F";
  }
}

class Person {
  get genderCode() {
    return this._genderCode;
  }
}

动机

子类很有用，它们为数据结构的多样和行为的多态提供支持，它们是针对差异编程的好工具。但随着软件的演化，子类所支持的变化可能会被搬移到别处，甚至完全去除，这时子类就失去了价值。有时添加子类是为了应对未来的功能，结果构想中的功能压根没被构造出来，或者用了另一种方式构造，使该子类不再被需要了。

子类存在着就有成本，阅读者要花心思去理解它的用意，所以如果子类的用处太少，就不值得存在了。此时，最好的选择就是移除子类，将其替换为超类中的一个字段。

做法

使用以工厂函数取代构造函数（334），把子类的构造函数包装到超类的工厂函数中。

如果构造函数的客户端用一个数组字段来决定实例化哪个子类，可以把这个判断逻辑放到超类的工厂函数中。

如果有任何代码检查子类的类型，先用提炼函数（106）把类型检查逻辑包装起来，然后用搬移函数（198）将其搬到超类。每次修改后执行测试。

新建一个字段，用于代表子类的类型。

将原本针对子类的类型做判断的函数改为使用新建的类型字段。

删除子类。

测试。

本重构手法常用于一次移除多个子类，此时需要先把这些子类都封装起来（添加工厂函数、搬移类型检查），然后再逐个将它们折叠到超类中。

范例

一开始，代码中遗留了两个子类。

class Person…
constructor(name) {
 this._name = name;
}
get name()    {return this._name;}
get genderCode() {return "X";}
// snip

class Male extends Person {
 get genderCode() {return "M";}
}

class Female extends Person {
 get genderCode() {return "F";}
}

如果子类就干这点儿事，那真的没必要存在。不过，在移除子类之前，通常有必要检查使用方代码是否有依赖于特定子类的行为，这样的行为需要被搬移到子类中。在这个例子里，我找到一些客户端代码基于子类的类型做判断，不过这也不足以成为保留子类的理由。

客户端…
const numberOfMales = people.filter(p => p instanceof Male).length;

每当想要改变某个东西的表现形式时，我会先将当下的表现形式封装起来，从而尽量减小对客户端代码的影响。对于“创建子类对象”而言，封装的方式就是以工厂函数取代构造函数（334）。在这里，实现工厂有两种方式。

最直接的方式是为每个构造函数分别创建一个工厂函数。

function createPerson(name) {
  return new Person(name);
}
function createMale(name) {
  return new Male(name);
}
function createFemale(name) {
  return new Female(name);
}

虽然这是最直接的选择，但这样的对象经常是从输入源加载出来，直接根据性别代码创建对象。

function loadFromInput(data) {
 const result = [];
 data.forEach(aRecord => {
  let p;
  switch (aRecord.gender) {
   case 'M': p = new Male(aRecord.name); break;
   case 'F': p = new Female(aRecord.name); break;
   default: p = new Person(aRecord.name);
  }
  result.push(p);
 });
 return result;
}

有鉴于此，我觉得更好的办法是先用提炼函数（106）把“选择哪个类来实例化”的逻辑提炼成工厂函数。

function createPerson(aRecord) {
 let p;
 switch (aRecord.gender) {
  case 'M': p = new Male(aRecord.name); break;
  case 'F': p = new Female(aRecord.name); break;
  default: p = new Person(aRecord.name);
 }
 return p;
}
function loadFromInput(data) {
 const result = [];
 data.forEach(aRecord => {
  result.push(createPerson(aRecord));
 });
 return result;
}

提炼完工厂函数后，我会对这两个函数做些清理。先用内联变量（123）简化 createPerson 函数：

function createPerson(aRecord) {
  switch (aRecord.gender) {
    case "M":
      return new Male(aRecord.name);
    case "F":
      return new Female(aRecord.name);
    default:
      return new Person(aRecord.name);
  }
}

再用以管道取代循环（231）简化 loadFromInput 函数：

function loadFromInput(data) {
  return data.map(aRecord => createPerson(aRecord));
}

工厂函数封装了子类的创建逻辑，但代码中还有一处用到 instanceof 运算符——这从来不会是什么好味道。我用提炼函数（106）把这个类型检查逻辑提炼出来。

客户端…
const numberOfMales = people.filter(p => isMale(p)).length;

function isMale(aPerson) {return aPerson instanceof Male;}

然后用搬移函数（198）将其移到 Person 类。

class Person…
get isMale() {return this instanceof Male;}
客户端…
const numberOfMales = people.filter(p => p.isMale).length;

重构到这一步，所有与子类相关的知识都已经安全地包装在超类和工厂函数中。（对于“超类引用子类”这种情况，通常我会很警惕，不过这段代码用不了一杯茶的工夫就会被干掉，所以也不用太担心。）

现在，添加一个字段来表示子类之间的差异。既然有来自别处的一个类型代码，直接用它也无妨。

class Person…
constructor(name, genderCode) {
  this._name = name;
  this._genderCode = genderCode || "X";
}

get genderCode() {return this._genderCode;}

在初始化时先将其设置为默认值。（顺便说一句，虽然大多数人可以归类为男性或女性，但确实有些人不是这两种性别中的任何一种。忽视这些人的存在，是一个常见的建模错误。）

首先从“男性”的情况开始，将相关逻辑折叠到超类中。为此，首先要修改工厂函数，令其返回一个 Person 对象，然后修改所有 instanceof 检查逻辑，改为使用性别代码字段。

function createPerson(aRecord) {
  switch (aRecord.gender) {
    case "M":
      return new Person(aRecord.name, "M");
    case "F":
      return new Female(aRecord.name);
    default:
      return new Person(aRecord.name);
  }
}
class Person…
get isMale() {return "M" === this._genderCode;}

此时我可以测试，删除 Male 子类，再次测试，然后对 Female 子类也如法炮制。

function createPerson(aRecord) {
  switch (aRecord.gender) {
    case "M":
      return new Person(aRecord.name, "M");
    case "F":
      return new Person(aRecord.name, "F");
    default:
      return new Person(aRecord.name);
  }
}

类型代码的分配有点儿失衡，默认情况没有类型代码，这种情况让我很烦心。未来阅读代码的人会一直好奇背后的原因。所以我更愿意现在做点儿修改，给所有情况都平等地分配类型代码——只要不会引入额外的复杂性就好。

function createPerson(aRecord) {
  switch (aRecord.gender) {
    case "M":
      return new Person(aRecord.name, "M");
    case "F":
      return new Person(aRecord.name, "F");
    default:
      return new Person(aRecord.name, "X");
  }
}
class Person…
constructor(name, genderCode) {
  this._name = name;
  this._genderCode = genderCode || "X";
}

12.8 提炼超类（Extract Superclass）

class Department {
 get totalAnnualCost() {...}
 get name() {...}
 get headCount() {...}
}

class Employee {
 get annualCost() {...}
 get name() {...}
 get id() {...}
}


class Party {
 get name() {...}
 get annualCost() {...}
}

class Department extends Party {
 get annualCost() {...}
 get headCount() {...}
}

class Employee extends Party {
 get annualCost() {...}
 get id() {...}
}

动机

如果我看见两个类在做相似的事，可以利用基本的继承机制把它们的相似之处提炼到超类。我可以用字段上移（353）把相同的数据搬到超类，用函数上移（350）搬移相同的行为。

很多技术作家在谈到面向对象时，认为继承必须预先仔细计划，应该根据“真实世界”的分类结构建立对象模型。真实世界的分类结构可以作为设计继承关系的提示，但还有很多时候，合理的继承关系是在程序演化的过程中才浮现出来的：我发现了一些共同元素，希望把它们抽取到一处，于是就有了继承关系。

另一种选择就是提炼类（182）。这两种方案之间的选择，其实就是继承和委托之间的选择，总之目的都是把重复的行为收拢一处。提炼超类通常是比较简单的做法，所以我会首选这个方案。即便选错了，也总有以委托取代超类（399）这瓶后悔药可吃。

做法

为原本的类新建一个空白的超类。

如果需要的话，用改变函数声明（124）调整构造函数的签名。

测试。

使用构造函数本体上移（355）、函数上移（350）和字段上移（353）手法，逐一将子类的共同元素上移到超类。

检查留在子类中的函数，看它们是否还有共同的成分。如果有，可以先用提炼函数（106）将其提炼出来，再用函数上移（350）搬到超类。

检查所有使用原本的类的客户端代码，考虑将其调整为使用超类的接口。

范例

下面这两个类，仔细考虑之下，是有一些共同之处的——它们都有名字（name），也都有月度成本（monthly cost）和年度成本（annual cost）的概念：

class Employee {
 constructor(name, id, monthlyCost) {
  this._id = id;
  this._name = name;
  this._monthlyCost = monthlyCost;
 }
 get monthlyCost() {return this._monthlyCost;}
 get name() {return this._name;}
 get id() {return this._id;}

 get annualCost() {
  return this.monthlyCost * 12;
 }
}

class Department {
 constructor(name, staff){
  this._name = name;
  this._staff = staff;
 }
 get staff() {return this._staff.slice();}
 get name() {return this._name;}

 get totalMonthlyCost() {
  return this.staff
   .map(e => e.monthlyCost)
   .reduce((sum, cost) => sum + cost);
 }
 get headCount() {
  return this.staff.length;
 }
 get totalAnnualCost() {
  return this.totalMonthlyCost * 12;
 }
}

可以为它们提炼一个共同的超类，更明显地表达出它们之间的共同行为。

首先创建一个空的超类，让原来的两个类都继承这个新的类。

class Party {}

class Employee extends Party {
 constructor(name, id, monthlyCost) {
  super();
  this._id = id;
  this._name = name;
  this._monthlyCost = monthlyCost;
 }
 // rest of class...
class Department extends Party {
 constructor(name, staff){
  super();
  this._name = name;
  this._staff = staff;
 }
 // rest of class...

在提炼超类时，我喜欢先从数据开始搬移，在 JavaScript 中就需要修改构造函数。我先用字段上移（353）把 name 字段搬到超类中。

class Party…
constructor(name){
  this._name = name;
}
class Employee…
constructor(name, id, monthlyCost) {
  super(name);
  this._id = id;
  this._monthlyCost = monthlyCost;
}
class Department…
constructor(name, staff){
  super(name);
  this._staff = staff;
}

把数据搬到超类的同时，可以用函数上移（350）把相关的函数也一起搬移。首先是 name 函数：

class Party…
get name() {return this._name;}
class Employee…
get name() {return this._name;}
class Department…
get name() {return this._name;}

有两个函数实现非常相似。

class Employee…
get annualCost() {
  return this.monthlyCost * 12;
}
class Department…
get totalAnnualCost() {
  return this.totalMonthlyCost * 12;
}

它们各自使用的函数 monthlyCost 和 totalMonthlyCost 名字和实现都不同，但意图却是一致。我可以用改变函数声明（124）将它们的名字统一。

class Department…
get totalAnnualCost() {
  return this.monthlyCost * 12;
}

get monthlyCost() { ... }

然后对计算年度成本的函数也做相似的改名：

class Department…
get annualCost() {
  return this.monthlyCost * 12;
}

现在可以用函数上移（350）把这个函数搬到超类了。

class Party…
get annualCost() {
  return this.monthlyCost * 12;
}
class Employee…
get annualCost() {
  return this.monthlyCost * 12;
}
class Department…
get annualCost() {
  return this.monthlyCost * 12;
}

12.9 折叠继承体系（Collapse Hierarchy）

class Employee {...}
class Salesman extends Employee {...}


class Employee {...}

动机

在重构类继承体系时，我经常把函数和字段上下移动。随着继承体系的演化，我有时会发现一个类与其超类已经没多大差别，不值得再作为独立的类存在。此时我就会把超类和子类合并起来。

做法

选择想移除的类：是超类还是子类？

我选择的依据是看哪个类的名字放在未来更有意义。如果两个名字都不够好，我就随便挑一个。

使用字段上移（353）、字段下移（361）、函数上移（350）和函数下移（359），把所有元素都移到同一个类中。

调整即将被移除的那个类的所有引用点，令它们改而引用合并后留下的类。

移除我们的目标；此时它应该已经成为一个空类。

测试。

12.10 以委托取代子类（Replace Subclass with Delegate）

class Order {
  get daysToShip() {
    return this._warehouse.daysToShip;
  }
}

class PriorityOrder extends Order {
  get daysToShip() {
    return this._priorityPlan.daysToShip;
  }
}

class Order {
  get daysToShip() {
    return this._priorityDelegate
      ? this._priorityDelegate.daysToShip
      : this._warehouse.daysToShip;
  }
}

class PriorityOrderDelegate {
  get daysToShip() {
    return this._priorityPlan.daysToShip;
  }
}

动机

如果一个对象的行为有明显的类别之分，继承是很自然的表达方式。我可以把共用的数据和行为放在超类中，每个子类根据需要覆写部分特性。在面向对象语言中，继承很容易实现，因此也是程序员熟悉的机制。

但继承也有其短板。最明显的是，继承这张牌只能打一次。导致行为不同的原因可能有多种，但继承只能用于处理一个方向上的变化。比如说，我可能希望“人”的行为根据“年龄段”不同，并且根据“收入水平”不同。使用继承的话，子类可以是“年轻人”和“老人”，也可以是“富人”和“穷人”，但不能同时采用两种继承方式。

更大的问题在于，继承给类之间引入了非常紧密的关系。在超类上做任何修改，都很可能破坏子类，所以我必须非常小心，并且充分理解子类如何从超类派生。如果两个类的逻辑分处不同的模块、由不同的团队负责，问题就会更麻烦。

这两个问题用委托都能解决。对于不同的变化原因，我可以委托给不同的类。委托是对象之间常规的关系。与继承关系相比，使用委托关系时接口更清晰、耦合更少。因此，继承关系遇到问题时运用以委托取代子类是常见的情况。

有一条流行的原则：“对象组合优于类继承”（“组合”跟“委托”是同一回事）。很多人把这句话解读为“继承有害”，并因此声称绝不应该使用继承。我经常使用继承，部分是因为我知道，如果稍后需要改变，我总可以使用以委托取代子类。继承是一种很有价值的机制，大部分时候能达到效果，不会带来问题。所以我会从继承开始，如果开始出现问题，再转而使用委托。这种用法与前面说的原则实际上是一致的——这条出自名著《设计模式》[gof]的原则解释了如何让继承和组合协同工作。这条原则之所以强调“组合优于继承”，其实是对彼时继承常被滥用的回应。

熟悉《设计模式》一书的读者可以这样来理解本重构手法，就是用状态（State）模式或者策略（Strategy）模式取代子类。这两个模式在结构上是相同的，都是由宿主对象把责任委托给另一个继承体系。以委托取代子类并非总会需要建立一个继承体系来接受委托（下面第一个例子就没有），不过建立一个状态或策略的继承体系经常都是有用的。

做法

如果构造函数有多个调用者，首先用以工厂函数取代构造函数（334）把构造函数包装起来。

创建一个空的委托类，这个类的构造函数应该接受所有子类特有的数据项，并且经常以参数的形式接受一个指回超类的引用。

在超类中添加一个字段，用于安放委托对象。

修改子类的创建逻辑，使其初始化上述委托字段，放入一个委托对象的实例。

这一步可以在工厂函数中完成，也可以在构造函数中完成（如果构造函数有足够的信息以创建正确的委托对象的话）。

选择一个子类中的函数，将其移入委托类。

使用搬移函数（198）手法搬移上述函数，不要删除源类中的委托代码。

如果这个方法用到的其他元素也应该被移入委托对象，就把它们一并搬移。如果它用到的元素应该留在超类中，就在委托对象中添加一个字段，令其指向超类的实例。

如果被搬移的源函数还在子类之外被调用了，就把留在源类中的委托代码从子类移到超类，并在委托代码之前加上卫语句，检查委托对象存在。如果子类之外已经没有其他调用者，就用移除死代码（237）去掉已经没人使用的委托代码。

如果有多个委托类，并且其中的代码出现了重复，就使用提炼超类（375）手法消除重复。此时如果默认行为已经被移入了委托类的超类，源超类的委托函数就不再需要卫语句了。

测试。

重复上述过程，直到子类中所有函数都搬到委托类。

找到所有调用子类构造函数的地方，逐一将其改为使用超类的构造函数。

测试。

运用移除死代码（237）去掉子类。

范例

下面这个类用于处理演出（show）的预订（booking）。

class Booking…
constructor(show, date) {
  this._show = show;
  this._date = date;
}

它有一个子类，专门用于预订高级（premium）票，这个子类要考虑各种附加服务（extra）。

class PremiumBooking extends Booking…
constructor(show, date, extras) {
  super(show, date);
  this._extras = extras;
}

PremiumBooking 类在超类基础上做了好些改变。在这种“针对差异编程”（programming-by-difference）的风格中，子类常会覆写超类的方法，有时还会添加只对子类有意义的新方法。我不打算讨论所有差异点，只选几处有意思的案例来分析。

先来看一处简单的覆写。常规票在演出结束后会有“对话创作者”环节（talkback），但只在非高峰日提供这项服务。

class Booking…
get hasTalkback() {
 return this._show.hasOwnProperty('talkback') &amp;&amp; !this.isPeakDay;
}

PremiumBooking 覆写了这个逻辑，任何一天都提供与创作者的对话。

class PremiumBooking…
get hasTalkback() {
  return this._show.hasOwnProperty('talkback');
}

定价逻辑也是相似的覆写，不过略有不同：PremiumBooking 调用了超类中的方法。

class Booking…
get basePrice() {
  let result = this._show.price;
  if (this.isPeakDay) result += Math.round(result * 0.15);
  return result;
}
class PremiumBooking…
get basePrice() {
  return Math.round(super.basePrice + this._extras.premiumFee);
}

最后一个例子是 PremiumBooking 提供了一个超类中没有的行为。

class PremiumBooking…
get hasDinner() {
  return this._extras.hasOwnProperty('dinner') &amp;&amp; !this.isPeakDay;
}

继承在这个例子中工作良好。即使不了解子类，我同样也可以理解超类的逻辑。子类只描述自己与超类的差异——既避免了重复，又清晰地表述了自己引入的差异。

说真的，它也并非如此完美。超类的一些结构只在特定的子类存在时才有意义——有些函数的组织方式完全就是为了方便覆写特定类型的行为。所以，尽管大部分时候我可以修改超类而不必理解子类，但如果刻意不关注子类的存在，在修改超类时偶尔有可能会破坏子类。不过，如果这种“偶尔”发生得不太频繁，继承就还是划算的——只要我有良好的测试，当子类被破坏时就能及时发现。

那么，既然情况还算不坏，为什么我想用以委托取代子类来做出改变呢？因为继承只能使用一次，如果我有别的原因想使用继承，并且这个新的原因比“高级预订”更有必要，就需要换一种方式来处理高级预订。另外，我可能需要动态地把普通预订升级成高级预订，例如提供 aBooking.bePremium()这样一个函数。有时我可以新建一个对象（就好像通过 HTTP 请求从服务器端加载全新的数据），从而避免“对象本身升级”的问题。但有时我需要修改数据本身的结构，而不重建整个数据结构。如果一个 Booking 对象被很多地方引用，也很难将其整个替换掉。此时，就有必要允许在“普通预订”和“高级预订”之间来回转换。

当这样的需求积累到一定程度时，我就该使用以委托取代子类了。现在客户端直接调用两个类的构造函数来创建不同的预订。

进行普通预订的客户端

aBooking = new Booking(show, date);

进行高级预订的客户端

aBooking = new PremiumBooking(show, date, extras);

去除子类会改变对象创建的方式，所以我要先用以工厂函数取代构造函数（334）把构造函数封装起来。

顶层作用域…
function createBooking(show, date) {
  return new Booking(show, date);
}
function createPremiumBooking(show, date, extras) {
  return new PremiumBooking(show, date, extras);
}

进行普通预订的客户端

aBooking = createBooking(show, date);

进行高级预订的客户端

aBooking = createPremiumBooking(show, date, extras);

然后新建一个委托类。这个类的构造函数参数有两部分：首先是指向 Booking 对象的反向引用，随后是只有子类才需要的那些数据。我需要传入反向引用，是因为子类的几个函数需要访问超类中的数据。有继承关系的时候，访问这些数据很容易；而在委托关系中，就得通过反向引用来访问。

class PremiumBookingDelegate…
constructor(hostBooking, extras) {
  this._host = hostBooking;
  this._extras = extras;
}

现在可以把新建的委托对象与 Booking 对象关联起来。在“创建高级预订”的工厂函数中修改即可。

顶层作用域…
function createPremiumBooking(show, date, extras) {
  const result = new PremiumBooking(show, date, extras);
  result._bePremium(extras);
  return result;
}
class Booking…
_bePremium(extras) {
  this._premiumDelegate = new PremiumBookingDelegate(this, extras);
}

_bePremium 函数以下划线开头，表示这个函数不应该被当作 Booking 类的公共接口。当然，如果最终我们希望允许普通预订转换成高级预订，这个函数也可以成为公共接口。

或者我也可以在 Booking 类的构造函数中构建它与委托对象之间的联系。为此，我需要以某种方式告诉构造函数“这是一个高级预订”：可以通过一个额外的参数，也可以直接通过 extras 参数来表示（如果我能确定这个参数只有高级预订才会用到的话）。不过我还是更愿意在工厂函数中构建这层联系，因为这样可以把意图表达得更明确。

结构设置好了，现在该动手搬移行为了。我首先考虑 hasTalkback 函数简单的覆写逻辑。现在的代码如下。

class Booking…
get hasTalkback() {
  return this._show.hasOwnProperty('talkback') &amp;&amp; !this.isPeakDay;
}
class PremiumBooking…
get hasTalkback() {
  return this._show.hasOwnProperty('talkback');
}

我用搬移函数（198）把子类中的函数搬到委托类中。为了让它适应新家，原本访问超类中数据的代码，现在要改为调用_host 对象。

class PremiumBookingDelegate…
get hasTalkback() {
  return this._host._show.hasOwnProperty('talkback');
}
class PremiumBooking…
get hasTalkback() {
  return this._premiumDelegate.hasTalkback;
}

测试，确保一切正常，然后把子类中的函数删掉：

class PremiumBooking…
get hasTalkback() {
  return this._premiumDelegate.hasTalkback;
}

再次测试，现在应该有一些测试失败，因为原本有些代码会用到子类上的 hasTalkback 函数。

现在我要修复这些失败的测试：在超类的函数中添加适当的分发逻辑，如果有代理对象存在就使用代理对象。这样，这一步重构就算完成了。

class Booking…
get hasTalkback() {
  return (this._premiumDelegate)
    ? this._premiumDelegate.hasTalkback
    : this._show.hasOwnProperty('talkback') &amp;&amp; !this.isPeakDay;
}

下一个要处理的是 basePrice 函数。

class Booking…
get basePrice() {
  let result = this._show.price;
  if (this.isPeakDay) result += Math.round(result * 0.15);
  return result;
}
class PremiumBooking…
get basePrice() {
  return Math.round(super.basePrice + this._extras.premiumFee);
}

情况大致相同，但有一点儿小麻烦：子类中调用了超类中的同名函数（在这种“子类扩展超类行为”的用法中，这种情况很常见）。把子类的代码移到委托类时，需要继续调用超类的逻辑——但我不能直接调用 this._host.basePrice，这会导致无穷递归，因为 _host 对象就是 PremiumBooking 对象自己。

有两个办法来处理这个问题。一种办法是，可以用提炼函数（106）把“基本价格”的计算逻辑提炼出来，从而把分发逻辑与价格计算逻辑拆开。（剩下的操作就跟前面的例子一样了。）

class Booking…
get basePrice() {
 return (this._premiumDelegate)
  ? this._premiumDelegate.basePrice
  : this._privateBasePrice;
}

get _privateBasePrice() {
 let result = this._show.price;
 if (this.isPeakDay) result += Math.round(result * 0.15);
 return result;
}
class PremiumBookingDelegate…
get basePrice() {
  return Math.round(this._host._privateBasePrice + this._extras.premiumFee);
}

另一种办法是，可以重新定义委托对象中的函数，使其成为基础函数的扩展。

class Booking…
get basePrice() {
  let result = this._show.price;
  if (this.isPeakDay) result += Math.round(result * 0.15);
  return (this._premiumDelegate)
    ? this._premiumDelegate.extendBasePrice(result)
    : result;
}
class PremiumBookingDelegate…
extendBasePrice(base) {
  return Math.round(base + this._extras.premiumFee);
}

两种办法都可行，我更偏爱后者一点儿，因为需要的代码较少。

最后一个例子是一个只存在于子类中的函数。

class PremiumBooking…
get hasDinner() {
  return this._extras.hasOwnProperty('dinner') &amp;&amp; !this.isPeakDay;
}

我把它从子类移到委托类。

class PremiumBookingDelegate…
get hasDinner() {
  return this._extras.hasOwnProperty('dinner') &amp;&amp; !this._host.isPeakDay;
}

然后在 Booking 类中添加分发逻辑。

class Booking…
get hasDinner() {
  return (this._premiumDelegate)
    ? this._premiumDelegate.hasDinner
    : undefined;
}

在 JavaScript 中，如果尝试访问一个没有定义的属性，就会得到 undefined，所以我在这个函数中也这样做。（尽管我直觉认为应该抛出错误，我所熟悉的其他面向对象动态语言就是这样做的。）

所有的行为都从子类中搬移出去之后，我就可以修改工厂函数，令其返回超类的实例。再次运行测试，确保一切都运转良好，然后我就可以删除子类。

顶层作用域…
function createPremiumBooking(show, date, extras) {
  const result = new PremiumBooking(show, date, extras);
  result._bePremium(extras);
  return result;
}
class PremiumBooking extends Booking …

只看这个重构本身，我并不觉得代码质量得到了提升。继承原本很好地应对了需求场景，换成委托以后，我增加了分发逻辑、双向引用，复杂度上升不少。不过这个重构可能还是值得的，因为现在“是否高级预订”这个状态可以改变了，并且我也可以用继承来达成其他目的了。如果有这些需求的话，去除原有的继承关系带来的损失可能还是划算的。

范例：取代继承体系

前面的例子展示了如何用以委托取代子类去除单个子类。还可以用这个重构手法去除整个继承体系。

function createBird(data) {
 switch (data.type) {
  case 'EuropeanSwallow':
   return new EuropeanSwallow(data);
  case 'AfricanSwallow':
   return new AfricanSwallow(data);
  case 'NorweigianBlueParrot':
   return new NorwegianBlueParrot(data);
  default:
   return new Bird(data);
 }
}

class Bird {
 constructor(data) {
  this._name = data.name;
  this._plumage = data.plumage;
 }
 get name()  {return this._name;}

 get plumage() {
  return this._plumage || "average";
 }
 get airSpeedVelocity() {return null;}
}

class EuropeanSwallow extends Bird {
 get airSpeedVelocity() {return 35;}
}

class AfricanSwallow extends Bird {
 constructor(data) {
  super (data);
  this._numberOfCoconuts = data.numberOfCoconuts;
 }
 get airSpeedVelocity() {
  return 40 - 2 * this._numberOfCoconuts;
 }
}

class NorwegianBlueParrot extends Bird {
 constructor(data) {
  super (data);
  this._voltage = data.voltage;
  this._isNailed = data.isNailed;
 }

 get plumage() {
  if (this._voltage > 100) return "scorched";
  else return this._plumage || "beautiful";
 }
 get airSpeedVelocity() {
  return (this._isNailed) ? 0 : 10 + this._voltage / 10;
 }
}

上面这个关于鸟儿（bird）的系统很快要有一个大变化：有些鸟是“野生的”（wild），有些鸟是“家养的”（captive），两者之间的行为会有很大差异。这种差异可以建模为 Bird 类的两个子类：WildBird 和 CaptiveBird。但继承只能用一次，所以如果想用子类来表现“野生”和“家养”的差异，就得先去掉关于“不同品种”的继承关系。

在涉及多个子类时，我会一次处理一个子类，先从简单的开始——在这里，最简单的当属 EuropeanSwallow（欧洲燕）。我先给它建一个空的委托类。

class EuropeanSwallowDelegate {}

委托类中暂时还没有传入任何数据或反向引用。在这个例子里，我会在需要时再引入这些参数。

现在需要决定如何初始化委托字段。由于构造函数接受的唯一参数 data 包含了所有的信息，我决定在构造函数中初始化委托字段。考虑到有多个委托对象要添加，我会建一个函数，其中根据类型码（data.type）来选择适当的委托对象。

class Bird…
constructor(data) {
 this._name = data.name;
 this._plumage = data.plumage;
 this._speciesDelegate = this.selectSpeciesDelegate(data);
}

 selectSpeciesDelegate(data) {
  switch(data.type) {
   case 'EuropeanSwallow':
    return new EuropeanSwallowDelegate();
   default: return null;
  }
 }

结构设置完毕，我可以用搬移函数（198）把 EuropeanSwallow 的 airSpeedVelocity 函数搬到委托对象中。

class EuropeanSwallowDelegate…
get airSpeedVelocity() {return 35;}
class EuropeanSwallow…
get airSpeedVelocity() {return this._speciesDelegate.airSpeedVelocity;}

修改超类的 airSpeedVelocity 函数，如果发现有委托对象存在，就调用之。

class Bird…
get airSpeedVelocity() {
  return this._speciesDelegate ? this._speciesDelegate.airSpeedVelocity : null;
}

然后，删除子类。

class EuropeanSwallow extends Bird {
  get airSpeedVelocity() {
    return this._speciesDelegate.airSpeedVelocity;
  }
}
顶层作用域…
function createBird(data) {
  switch (data.type) {
    case "EuropeanSwallow":
      return new EuropeanSwallow(data);
    case "AfricanSwallow":
      return new AfricanSwallow(data);
    case "NorweigianBlueParrot":
      return new NorwegianBlueParrot(data);
    default:
      return new Bird(data);
  }
}

接下来处理 AfricanSwallow（非洲燕）子类。为它创建一个委托类，这次委托类的构造函数需要传入 data 参数。

class AfricanSwallowDelegate…
constructor(data) {
  this._numberOfCoconuts = data.numberOfCoconuts;
}

class Bird…

selectSpeciesDelegate(data) {
 switch(data.type) {
  case 'EuropeanSwallow':
   return new EuropeanSwallowDelegate();
  case 'AfricanSwallow':
   return new AfricanSwallowDelegate(data);
  default: return null;
 }
}

同样用搬移函数（198）把 airSpeedVelocity 搬到委托类中。

class AfricanSwallowDelegate…
get airSpeedVelocity() {
  return 40 - 2 * this._numberOfCoconuts;
}
class AfricanSwallow…
get airSpeedVelocity() {
  return this._speciesDelegate.airSpeedVelocity;
}

再删掉 AfricanSwallow 子类。

class AfricanSwallow extends Bird {
  // all of the body ...
}

function createBird(data) {
  switch (data.type) {
    case "AfricanSwallow":
      return new AfricanSwallow(data);
    case "NorweigianBlueParrot":
      return new NorwegianBlueParrot(data);
    default:
      return new Bird(data);
  }
}

接下来是 NorwegianBlueParrot（挪威蓝鹦鹉）子类。创建委托类和搬移 airSpeed Velocity 函数的步骤都跟前面一样，所以我直接展示结果好了。

class Bird…
selectSpeciesDelegate(data) {
 switch(data.type) {
  case 'EuropeanSwallow':
   return new EuropeanSwallowDelegate();
  case 'AfricanSwallow':
   return new AfricanSwallowDelegate(data);
  case 'NorweigianBlueParrot':
   return new NorwegianBlueParrotDelegate(data);
  default: return null;
 }
}
class NorwegianBlueParrotDelegate…
constructor(data) {
  this._voltage = data.voltage;
  this._isNailed = data.isNailed;
}
get airSpeedVelocity() {
  return (this._isNailed) ? 0 : 10 + this._voltage / 10;
}

一切正常。但 NorwegianBlueParrot 还覆写了 plumage 属性，前面两个例子则没有。首先我还是用搬移函数（198）把 plumage 函数搬到委托类中，这一步不难，不过需要修改构造函数，放入对 Bird 对象的反向引用。

class NorwegianBlueParrot…
get plumage() {
  return this._speciesDelegate.plumage;
}
class NorwegianBlueParrotDelegate…
get plumage() {
 if (this._voltage > 100) return "scorched";
 else return this._bird._plumage || "beautiful";
}

constructor(data, bird) {
 this._bird = bird;
 this._voltage = data.voltage;
 this._isNailed = data.isNailed;
}
class Bird…
selectSpeciesDelegate(data) {
 switch(data.type) {
  case 'EuropeanSwallow':
   return new EuropeanSwallowDelegate();
  case 'AfricanSwallow':
   return new AfricanSwallowDelegate(data);
  case 'NorweigianBlueParrot':
   return new NorwegianBlueParrotDelegate(data, this);
  default: return null;
 }
}

麻烦之处在于如何去掉子类中的 plumage 函数。如果我像下面这么干就会得到一大堆错误，因为其他品种的委托类没有 plumage 这个属性。

class Bird…
get plumage() {
  if (this._speciesDelegate)
    return this._speciesDelegate.plumage;
  else
    return this._plumage || "average";
}

我可以做一个更明确的条件分发：

class Bird…
get plumage() {
  if (this._speciesDelegate instanceof NorwegianBlueParrotDelegate)
    return this._speciesDelegate.plumage;
  else
    return this._plumage || "average";
}

不过我超级反感这种做法，希望你也能闻出同样的坏味道。像这样的显式类型检查几乎总是坏主意。

另一个办法是在其他委托类中实现默认的行为。

class Bird…
get plumage() {
  if (this._speciesDelegate)
    return this._speciesDelegate.plumage;
  else
    return this._plumage || "average";
}
class EuropeanSwallowDelegate…
get plumage() {
  return this._bird._plumage || "average";
}
class AfricanSwallowDelegate…
get plumage() {
  return this._bird._plumage || "average";
}

但这又造成了 plumage 默认行为的重复。如果这还不够糟糕的话，还有一个“额外奖励”：构造函数中给_bird 反向引用赋值的代码也会重复。

解决重复的办法，很自然，就是继承——用提炼超类（375）从各个代理类中提炼出一个共同继承的超类。

class SpeciesDelegate {
 constructor(data, bird) {
  this._bird = bird;
 }
 get plumage() {
  return this._bird._plumage || "average";
 }

class EuropeanSwallowDelegate extends SpeciesDelegate {

class AfricanSwallowDelegate extends SpeciesDelegate {
 constructor(data, bird) {
  super(data,bird);
  this._numberOfCoconuts = data.numberOfCoconuts;
}

class NorwegianBlueParrotDelegate extends SpeciesDelegate {
 constructor(data, bird) {
  super(data, bird);
  this._voltage = data.voltage;
  this._isNailed = data.isNailed;
}

有了共同的超类以后，就可以把 SpeciesDelegate 字段默认设置为这个超类的实例，并把 Bird 类中的默认行为搬移到 SpeciesDelegate 超类中。

class Bird…
selectSpeciesDelegate(data) {
 switch(data.type) {
  case 'EuropeanSwallow':
   return new EuropeanSwallowDelegate(data, this);
  case 'AfricanSwallow':
   return new AfricanSwallowDelegate(data, this);
  case 'NorweigianBlueParrot':
   return new NorwegianBlueParrotDelegate(data, this);
  default: return new SpeciesDelegate(data, this);
 }
}
// rest of bird’s code...

get plumage() {return this._speciesDelegate.plumage;}

get airSpeedVelocity() {return this._speciesDelegate.airSpeedVelocity;}
class SpeciesDelegate…
get airSpeedVelocity() {return null;}

我喜欢这种办法，因为它简化了 Bird 类中的委托函数。我可以一目了然地看到哪些行为已经被委托给 SpeciesDelegate，哪些行为还留在 Bird 类中。

这几个类最终的状态如下：

function createBird(data) {
 return new Bird(data);
}
class Bird {
 constructor(data) {
  this._name = data.name;
  this._plumage = data.plumage;
  this._speciesDelegate = this.selectSpeciesDelegate(data);
 }
 get name()    {return this._name;}
 get plumage() {return this._speciesDelegate.plumage;}
 get airSpeedVelocity() {return this._speciesDelegate.airSpeedVelocity;}

 selectSpeciesDelegate(data) {
  switch(data.type) {
   case 'EuropeanSwallow':
    return new EuropeanSwallowDelegate(data, this);
   case 'AfricanSwallow':
    return new AfricanSwallowDelegate(data, this);
   case 'NorweigianBlueParrot':
    return new NorwegianBlueParrotDelegate(data, this);
   default: return new SpeciesDelegate(data, this);
  }
 }
 // rest of bird’s code...
}

class SpeciesDelegate {
 constructor(data, bird) {
  this._bird = bird;
 }
 get plumage() {
  return this._bird._plumage || "average";
 }
 get airSpeedVelocity() {return null;}
}

class EuropeanSwallowDelegate extends SpeciesDelegate {
 get airSpeedVelocity() {return 35;}
}

class AfricanSwallowDelegate extends SpeciesDelegate {
 constructor(data, bird) {
  super(data,bird);
  this._numberOfCoconuts = data.numberOfCoconuts;
 }
 get airSpeedVelocity() {
  return 40 - 2 * this._numberOfCoconuts;
 }
}

class NorwegianBlueParrotDelegate extends SpeciesDelegate {
 constructor(data, bird) {
  super(data, bird);
  this._voltage = data.voltage;
  this._isNailed = data.isNailed;
 }
 get airSpeedVelocity() {
  return (this._isNailed) ? 0 : 10 + this._voltage / 10;
 }
 get plumage() {
  if (this._voltage > 100) return "scorched";
  else return this._bird._plumage || "beautiful";
 }
}

在这个例子中，我用一系列委托类取代了原来的多个子类，与原来非常相似的继承结构被转移到了 SpeciesDelegate 下面。除了给 Bird 类重新被继承的机会，从这个重构中我还有什么收获？新的继承体系范围更收拢了，只涉及各个品种不同的数据和行为，各个品种相同的代码则全都留在了 Bird 中，它未来的子类也将得益于这些共用的行为。

在前面的“演出预订”的例子中，我也可以采用同样的手法，创建一个委托超类。这样在 Booking 类中就不需要分发逻辑，直接调用委托对象即可，让继承关系来搞定分发。不过写到这儿，我要去吃晚饭了，就把这个练习留给读者吧。

从这两个例子看来，“对象组合优于类继承”这句话更确切的表述可能应该是“审慎地组合使用对象组合与类继承，优于单独使用其中任何一种”——不过这就不太上口了。

12.11 以委托取代超类（Replace Superclass with Delegate）

曾用名：以委托取代继承（Replace Inheritance with Delegation）

class List {...}
class Stack extends List {...}


class Stack {
  constructor() {
    this._storage = new List();
  }
}
class List {...}

动机

在面向对象程序中，通过继承来复用现有功能，是一种既强大又便捷的手段。我只要继承一个已有的类，覆写一些功能，再添加一些功能，就能达成目的。但继承也有可能造成困扰和混乱。

在对象技术发展早期，有一个经典的误用继承的例子：让栈（stack）继承列表（list）。这个想法的出发点是想复用列表类的数据存储和操作能力。虽说复用是一件好事，但这个继承关系有问题：列表类的所有操作都会出现在栈类的接口上，然而其中大部分操作对一个栈来说并不适用。更好的做法应该是把列表作为栈的字段，把必要的操作委派给列表就行了。

这就是一个用得上以委托取代超类手法的例子——如果超类的一些函数对子类并不适用，就说明我不应该通过继承来获得超类的功能。

除了“子类用得上超类的所有函数”之外，合理的继承关系还有一个重要特征：子类的所有实例都应该是超类的实例，通过超类的接口来使用子类的实例应该完全不出问题。假如我有一个车模（car model）类，其中有名称、引擎大小等属性，我可能想复用这些特性来表示真正的汽车（car），并在子类上添加 VIN 编号、制造日期等属性。然而汽车终归不是模型。这是一种常见而又经常不易察觉的建模错误，我称之为“类型与实例名不符实”（type-instance homonym）[mf-tih]。

在这两个例子中，有问题的继承招致了混乱和错误——如果把继承关系改为将部分职能委托给另一个对象，这些混乱和错误本是可以轻松避免的。使用委托关系能更清晰地表达“这是另一个东西，我只是需要用到其中携带的一些功能”这层意思。

即便在子类继承是合理的建模方式的情况下，如果子类与超类之间的耦合过强，超类的变化很容易破坏子类的功能，我还是会使用以委托取代超类。这样做的缺点就是，对于宿主类（也就是原来的子类）和委托类（也就是原来的超类）中原本一样的函数，现在我必须在宿主类中挨个编写转发函数。不过还好，这种转发函数虽然写起来乏味，但它们都非常简单，几乎不可能出错。

有些人在这个方向上走得更远，他们建议完全避免使用继承，但我不同意这种观点。如果符合继承关系的语义条件（超类的所有方法都适用于子类，子类的所有实例都是超类的实例），那么继承是一种简洁又高效的复用机制。如果情况发生变化，继承不再是最好的选择，我也可以比较容易地运用以委托取代超类。所以我的建议是，首先（尽量）使用继承，如果发现继承有问题，再使用以委托取代超类。

做法

在子类中新建一个字段，使其引用超类的一个对象，并将这个委托引用初始化为超类的新实例。

针对超类的每个函数，在子类中创建一个转发函数，将调用请求转发给委托引用。每转发一块完整逻辑，都要执行测试。

大多数时候，每转发一个函数就可以测试，但一对设值/取值必须同时转移，然后才能测试。

当所有超类函数都被转发函数覆写后，就可以去掉继承关系。

范例

我最近给一个古城里存放上古卷轴（scroll）的图书馆做了咨询。他们给卷轴的信息编制了一份目录（catalog），每份卷轴都有一个 ID 号，并记录了卷轴的标题（title）和一系列标签（tag）。

class CatalogItem…
constructor(id, title, tags) {
 this._id = id;
 this._title = title;
 this._tags = tags;
}

get id() {return this._id;}
get title() {return this._title;}
hasTag(arg) {return this._tags.includes(arg);}

这些古老的卷轴需要日常清扫，因此代表卷轴的 Scroll 类继承了代表目录项的 CatalogItem 类，并扩展出与“需要清扫”相关的数据。

class Scroll extends CatalogItem…
constructor(id, title, tags, dateLastCleaned) {
 super(id, title, tags);
 this._lastCleaned = dateLastCleaned;
}

needsCleaning(targetDate) {
 const threshold = this.hasTag("revered") ? 700 : 1500;
 return this.daysSinceLastCleaning(targetDate) > threshold ;
}
daysSinceLastCleaning(targetDate) {
 return this._lastCleaned.until(targetDate, ChronoUnit.DAYS);
}

这就是一个常见的建模错误。真实存在的卷轴和只存在于纸面上的目录项，是完全不同的两种东西。比如说，关于“如何治疗灰鳞病”的卷轴可能有好几卷，但在目录上却只记录一个条目。

这样的建模错误很多时候可以置之不理。像“标题”和“标签”这样的数据，我可以认为就是目录中数据的副本。如果这些数据从不发生改变，我完全可以接受这样的表现形式。但如果需要更新其中某处数据，我就必须非常小心，确保同一个目录项对应的所有数据副本都被正确地更新。

就算没有数据更新的问题，我还是希望改变这两个类之间的关系。把“目录项”作为“卷轴”的超类很可能会把未来的程序员搞迷糊，因此这是一个糟糕的模型。

我首先在 Scroll 类中创建一个属性，令其指向一个新建的 CatalogItem 实例。

class Scroll extends CatalogItem…
constructor(id, title, tags, dateLastCleaned) {
  super(id, title, tags);
  this._catalogItem = new CatalogItem(id, title, tags);
  this._lastCleaned = dateLastCleaned;
}

然后对于子类中用到所有属于超类的函数，我要逐一为它们创建转发函数。

class Scroll…
get id() {return this._catalogItem.id;}
get title() {return this._catalogItem.title;}
hasTag(aString) {return this._catalogItem.hasTag(aString);}

最后去除 Scroll 与 CatalogItem 之间的继承关系。

class Scroll extends CatalogItem{
  constructor(id, title, tags, dateLastCleaned) {
    super(id, title, tags);
    this._catalogItem = new CatalogItem(id, title, tags);
    this._lastCleaned = dateLastCleaned;
  }

基本的以委托取代超类重构到这里就完成了，不过在这个例子中，我还有一点收尾工作要做。

前面的重构把 CatalogItem 变成了 Scroll 的一个组件：每个 Scroll 对象包含一个独一无二的 CatalogItem 对象。在使用本重构的很多情况下，这样处理就够了。但在这个例子中，更好的建模方式应该是：关于灰鳞病的一个目录项，对应于图书馆中的 6 份卷轴，因为这 6 份卷轴都是同一个标题。这实际上是要运用将值对象改为引用对象（256）。

不过在使用将值对象改为引用对象（256）之前，还有一个问题需要先修好。在原来的继承结构中，Scroll 类使用了 CatalogItem 类的 id 字段来保存自己的 ID。但如果我把 CatalogItem 当作引用来处理，那么透过这个引用获得的 ID 就应该是目录项的 ID，而不是卷轴的 ID。也就是说，我需要在 Scroll 类上添加 id 字段，在创建 Scroll 对象时使用这个字段，而不是使用来自 CatalogItem 类的 id 字段。这一步既可以说是搬移，也可以说是拆分。

class Scroll…
constructor(id, title, tags, dateLastCleaned) {
  this._id = id;
  this._catalogItem = new CatalogItem(null, title, tags);
  this._lastCleaned = dateLastCleaned;
}

get id() {return this._id;}

用 null 作为 ID 值创建目录项，这种操作一般而言应该触发警报了，不过这只是我在重构过程中的临时状态，可以暂时忍受。等我重构完成，多个卷轴会指向一个共享的目录项，而后者也会有合适的 ID。

当前 Scroll 对象是从一个加载程序中加载的。

加载程序…
const scrolls = aDocument
  .map(record => new Scroll(record.id,
              record.catalogData.title,
              record.catalogData.tags,
              LocalDate.parse(record.lastCleaned)));

将值对象改为引用对象（256）的第一步是要找到或者创建一个仓库对象（repository）。我发现有一个仓库对象可以很容易地导入加载程序中，这个仓库对象负责提供 CatalogItem 对象，并用 ID 作为索引。我的下一项任务就是要想办法把这个 ID 值放进 Scroll 对象的构造函数。还好，输入数据中有这个值，不过之前一直被无视了，因为在使用继承的时候用不着。把这些信息都理清楚，我就可以运用改变函数声明（124），把整个目录对象以及目录项的 ID 都作为参数传给 Scroll 的构造函数。

加载程序…
const scrolls = aDocument
  .map(record => new Scroll(record.id,
              record.catalogData.title,
              record.catalogData.tags,
              LocalDate.parse(record.lastCleaned),
              record.catalogData.id,
              catalog));
class Scroll…
  constructor(id, title, tags, dateLastCleaned, catalogID, catalog) {
 this._id = id;
 this._catalogItem = new CatalogItem(null, title, tags);
 this._lastCleaned = dateLastCleaned;
}

然后修改 Scroll 的构造函数，用传入的 catalogID 来查找对应的 CatalogItem 对象，并引用这个对象（而不再新建 CatalogItem 对象）。

class Scroll…
constructor(id, title, tags, dateLastCleaned, catalogID, catalog) {
  this._id = id;
  this._catalogItem = catalog.get(catalogID);
  this._lastCleaned = dateLastCleaned;
}

Scroll 的构造函数已经不再需要传入 title 和 tags 这两个参数了，所以我用改变函数声明（124）把它们去掉。

加载程序…
const scrolls = aDocument
  .map(record => new Scroll(record.id,
              record.catalogData.title,
              record.catalogData.tags,
              LocalDate.parse(record.lastCleaned),
              record.catalogData.id,
              catalog));
class Scroll…
  constructor(id, title, tags, dateLastCleaned, catalogID, catalog) {
 this._id = id;
 this._catalogItem = catalog.get(catalogID);
 this._lastCleaned = dateLastCleaned;
}
csdn_life18
关注
《重构：改善既有代码的设计》读书笔记(上)
行走
07-02 1327
重构：改善既有代码的设计
重构-改善既有代码的设计 pdf
qq_43679402的博客
11-14 5048
重构-改善既有代码的设计 pdf
重构----改善既有代码的设计(完整中文扫描版PDF).pdf
07-10
本书讲述重构,即在不改变软件现有功能的基础上，通过调整程序代码改善软件的质量、性能，使其程序的设计模式和架构更趋合理，提高软件的扩展性和维护性。
重构改善既有代码的设计第2版 PDF 下载
gitblog_06697的博客
09-26 967
重构改善既有代码的设计第2版 PDF 下载 【下载地址】重构改善既有代码的设计第2版PDF下载 - **文件名**: 重构改善既有代码的设计第2版.pdf- **文件类型**: PDF- **文件大小**: [文件大小]- **适用人群**: 软件开发人员、架构师、项目经理等 ...
《重构改善既有代码的设计第2版》PDF下载：提升代码质量的必备指南
gitblog_06633的博客
09-26 755
《重构改善既有代码的设计第2版》PDF下载：提升代码质量的必备指南 【下载地址】重构改善既有代码的设计第2版PDF下载 - **文件名**: 重构改善既有代码的设计第2版.pdf- **文件类型**: PDF- **文件大小**: [文件大小]- **适用人群**: 软件开发人员、架构师、项目经理等 ...
重构_改善既有代码的设计_第二版(Java代码示例)
a5f4s6f4a65f4a6sf的博客
06-21 5607
前言 最近在读《重构_改善既有代码的设计(第2版)》这本书，一本非常经典，并且非常容易读懂的书，强力推荐刚入职场或未入职场的同学去读，书中的代码示例是用JavaScript来编写的，该文只是将书中的代码示例翻译成Java版本，并不会复制书中过多的内容，其中一些做法并不完全相同，加了自己的风格或者是说一些浅显的理解，非常欢迎各位批评和指正。 第一个示例 示例需求: 设想有一个戏剧演出团，演员们经常要...
重构 改善既有代码的设计 pdf 中文
03-13
重构 改善既有代码的设计 pdf 中文
[读书笔记] 重构改善既有代码的设计（2）
beyongwang的博客
02-26 620
整理第三章的内容，关于代码的坏味道，这些往往也是可以进行重构的信号。 1. 重复代码。这个是非常常见的代码结构问题，这样的代码问题也很明显：难以维护，重复代码意味着当一份代码改动时，另一份也必须做出相应的改动，否则就会出现不一致的问题。这种情况应该提取共同代码。 2. 过长函数。函数过长意味着函数很复杂，处理了好多内容，违背单一职责，同时，程序愈长愈时难以理解，也很难为其起一个合适的可以表其意的
重构-改善既有代码的设计(chm清晰版)
12-12
章节一 重构，第一个案例 章节二 重构原则 章节三 代码的坏味道 章节四 构筑测试体系 章节五 重构名录 章节六 重新组织你的函数 章节七 在对象之间搬移特性 章节八 重新组织数据 章节九 简化条件表达式 章节十 简化...
Java版水果管理系统源码-RefactorMindMap:重构第一版重构手法读书笔记思维导图
06-05
重构：改善既有代码的设计 第一版以OOP为主 针对书本的核心部分6-11章做了思维导图可视化。 突然发现第二版上个月上市，直接下单了精装版，把这个坑填完我就自己去读第二版了哈哈 Link 第二版安利 为什么决定再版...
重构_重构_改善既有代码_
10-03
重构——改善既有代码设计，经典文档，架构师必须教程
重构----改善既有代码的设计(完整中文扫描版PDF)
01-16
重构----改善既有代码的设计(完整中文扫描版PDF)
重构-改善即有代码的设计.pdf
09-28
重构-改善即有代码的设计.pdf，经典，经典，经典，必看
重构改善既有代码的设计第2版.pdf
10-27
重构改善既有代码的设计第2版.pdf
重构: 改善既有代码设计 - 第二版 第1--5章
最新发布
csdn_life18的博客
10-30 1531
重构: 改善既有代码设计 - 第二版 第1–5章 作者: Martin Fowler 从前，有位咨询顾问造访客户调研其开发项目。该系统的核心是一个类继承体系，顾问看了开发人员所写的一些代码。他发现整个体系相当凌乱，上层超类对系统的工作方式做了一些假设，下层子类实现这些假设。但是这些假设并不适合所有子类，导致覆写（override）工作非常繁重。只要在超类做点修改，就可以减少许多覆写工作。在另一些地方，超类的某些意图并未被良好理解，因此其中某些行为在子类内重复出现。还有一些地方，好几个子类做相同的事情，其实可
[读书笔记] 重构 - 改善既有代码的设计第二版
Young's Blog
12-02 818
refactoring-cheat-sheet 《重构 改善既有代码的设计第二版》中文版 注意：《重构》书籍中的代码示范，有些展示的不合理，没有与文字解释同步好 第 1 章 重构，第一个示例 将业务流转逻辑与计算逻辑拆分，简单点说，流转逻辑中使用的计算参数使用计算函数进行拆分出来，消除局部变量。 在重构和添加新特性之间寻找平衡。 重复的代码片段需要进行提取，抽象成公共的函数，便于维护。 代码复审有助于在开发团队中传播知识，也有助于让较有经验的开发者把知识传递给比较欠缺经验的人，并帮助更多人理解大型软件系.
《重构-改善既有代码的设计》pdf
weixin_30727835的博客
05-15 552
下载地址：网盘下载 编辑推荐 编辑 软件工程领域的超级经典巨著，与另一巨著《设计模式》并称"软工双雄"，全美销量超过100000册，亚马逊书店五星书。 在本书中，作者Martin Fowler充分展示了何处可能需要重构，以及如何将不好的设计改造为良好的设计。 当对象技术成为老生常谈之后——尤其在Java编程语言之中，新的问题也在软件开发社...
实践《重构：改善既有代码的设计（第2版）》示例（C++版）（一）
小小笑笑川的博客
07-15 1757
最近在拜读《重构：改善既有代码的设计》(第二版)，与GoF的《设计模式》一同被誉为软件工程师的两本圣经。通过C++来改写书中案例，一方面为了自己更好地理解，另一方面为志同道合的C++爱好者提供一份参考
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值