《重构 改善既有代码的设计》

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;
}