曾用名：以委托取代继承（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; } ```