重构改善既有代码的设计-学习（六）：处理继承关系

最新推荐文章于 2024-11-01 15:17:02 发布

玉面大蛟龙

最新推荐文章于 2024-11-01 15:17:02 发布

阅读量1.3k

点赞数 18

分类专栏：架构文章标签：重构学习

本文链接：https://blog.csdn.net/m0_49499183/article/details/135899292

版权

架构专栏收录该内容

24 篇文章 5 订阅

订阅专栏

1、函数上移（Pull Up Method）

无论何时，只要系统内出现重复，你就会面临“修改其中一个却未能修改另一个”的风险。通常，找出重复也有一定的难度。

所以，某个函数在各个子类中的函数体都相同（它们很可能是通过复制粘贴得到的），这就需要使用函数上移，也就是将共同的函数上移到超类中。

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

2、字段上移（Pull Up Field）

如果各子类是分别开发的，或者是在重构过程中组合起来的，你常会发现它们拥有重复特性，特别是字段更容易重复。

如果它们被使用的方式很相似，就可以将它们提升到超类中去。

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

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

如果重构过程过于复杂，可以考虑转而使用以工厂函数取代构造函数（详见：重构改善既有代码的设计-学习（五）：重构API-CSDN博客）。

4、函数下移（Push Down Method）

如果超类中的某个函数只与一个（或少数几个）子类有关，那么最好将其从超类中挪走，放到真正关心它的子类中去。

5、字段下移（Push Down Field）

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

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

软件系统经常使用类型码表现“相似但又不同的东西”。大多数时候，有这样的类型码就够了。但也有些时候，可以再多往前一步，引入子类。

继承有两个诱人之处：

你可以用多态来处理条件逻辑。如果有几个函数都在根据类型码的取值采取不同的行为，多态就显得特别有用。引入子类之后，我可以用以多态取代条件表达式（详见：重构改善既有代码的设计-学习（四）：简化条件逻辑-CSDN博客）来处理这些函数。
有些字段或函数只对特定的类型码取值才有意义，此时可以创建子类，然后用字段下移把这样的字段放到合适的子类中去。

例如：

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

7、移除子类（Remove Subclass）

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

8、提炼超类（Extract Superclass）

如果看见两个类在做相似的事，可以利用基本的继承机制把它们的相似之处提炼到超类

9、折叠继承体系（Collapse Hierarchy）

如果发现一个类与其超类已经没多大差别，不值得再作为独立的类存在，就需要把超类和子类合并起来

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

如果一个对象的行为有明显的类别之分，继承是很自然的表达方式。我可以把共用的数据和行为放在超类中，每个子类根据需要覆写部分特性。

但继承也有其短板，他只能用于处理一个方向上的变化，并且继承给类之间引入了非常紧密的关系。在超类上做任何修改，都很可能破坏子类。

用委托可以解决这两个问题。对于不同的变化原因，我可以委托给不同的类。与继承关系相比，使用委托关系时接口更清晰、耦合更少。

可以用设计模式来理解本重构手法，就是用状态（State）模式或者策略（Strategy）模式
取代子类。这两个模式在结构上是相同的，都是由宿主对象把责任委托给另一个继承体系。

例子：

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

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

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

如果子类与超类之间的耦合过强，超类的变化很容易破坏子类的功能，此时就可以使用以委托取代超类。

这样做的缺点就是，对于宿主类（也就是原来的子类）和委托类（也就是原来的超类）中原本一样的函数，现在我必须在宿主类中挨个编写转发函数。

例子：

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

改为：

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