继承与衍生。

大家叙述了ES6中增加的新类系统软件，用以解决创建对象构造方法的零碎状况。大家展现了怎么使用它来撰写以下编码:

class Circle {
    constructor(radius) {
        this.radius = radius;
        Circle.circlesMade  ;
    };

    static draw(circle, canvas) {
        // Canvas drawing code
    };

    static get circlesMade() {
        return !this._count ? 0 : this._count;
    };
    static set circlesMade(val) {
        this._count = val;
    };

    area() {
        return Math.pow(this.radius, 2) * Math.PI;
    };

    get radius() {
        return this._radius;
    };
    set radius(radius) {
        if (!Number.isInteger(radius))
            throw new Error("Circle radius must be an integer.");
        this._radius = radius;
    };
}

悲剧的是，如同一些人强调的那般，那时候没有时间探讨ES6中别的类的强悍作用。与传统的的类系统软件(比如c 或Java)一样，ES6容许承继，即一个类应用另一个类做为基类，随后根据加上自个的大量特点来扩大它。使我们细心看一下这一新特征的概率。

在进行探讨派生类以前，花一点时间回望一下特性承继和动态性原型链是很实用的。

JavaScript承继

在我们建立一个目标时，大家还有机会给它加上特性，但它也传承了它的原形目标的特性。JavaScript程序猿将娴熟的应用目前的Object.createAPI，轻轻松松保证这一点:

var proto = {
    value: 4,
    method() { return 14; }
}

var obj = Object.create(proto);

obj.value; // 4
obj.method(); // 14

除此之外，在我们给obj加上与proto上同样名字的特性时，obj上的特性会遮盖掉proto上的特性:

obj.value = 5;
obj.value; // 5
proto.value; // 4

派生类基本上关键点

记牢一点，大家现在可以见到应当如何连接由类建立的目标的原型链。回忆一下，在我们建立一个类时，大家构建了一个新涵数，与类界定中包括全部静态方法的constructor方式比较应。大家还构建了一个目标做为所建立涵数的prototype特性，它将包括全部的实例方法(instance method)。为了更好地建立承继全部静态数据特性的新类，大家一定要使新涵数目标承继父类的涵数目标。相近地，针对实例方法，大家一定要使新涵数的prototype目标承继父类的prototype目标。

这类叙述比较复杂。使我们试着一个实例，展现怎样在不加上新英语的语法的情形下将其相互连接，随后加上一个无足轻重的拓展，使其更美观大方。再次之前的事例，假定大家有一个要想被承继的Shape类:

class Shape {
    get color() {
        return this._color;
    }
    set color(c) {
        this._color = parseColorAsRGB(c);
        this.markChanged();  // repaint the canvas later
    }
}

在我们尝试撰写那样的源代码时，大家碰到了与上一篇有关静态数据特性的文章内容一样的难题：在界定涵数时，沒有一种英语的语法方式能够更改它的原形。你能用Object.setPrototypeOf来处理这个问题。针对模块而言，这类办法的性能指标和可提升耐热性比不上应用预估原形建立涵数的方式 。

class Circle {
    // As above
}

// Hook up the instance properties
Object.setPrototypeOf(Circle.prototype, Shape.prototype);

// Hook up the static properties
Object.setPrototypeOf(Circle, Shape);

这太丑陋了。大家增加了类英语的语法，那样大家就可以封裝有关最后目标在一个地区的外型的全部逻辑性，而不是在以后应用Object.setPrototypeOf的逻辑性。Java、Ruby和别的面向对象编程语言表达都是有一种方式来申明一个类申明是另一个类的派生类，大家也需要那样做。大家应用关键词extends，因此 还可以那样写:

class Circle extends Shape {
    // As above
}

你能够在extends后边放一切你愿意的关系式，只需它是一个带prototype特性的合理constructor涵数。比如:

• 另一个class
• 从目前的承继架构中的类class的涵数
• 一个一般function
• 一个意味着涵数或类的自变量
• 一个调用函数：func()
• 一个对目标特性的浏览：obj.name

假如我不期待案例承继Object.prototype，你乃至能够应用null。

父类的特性（super properties）

我们可以建立派生类，我们可以承继特性，有时候让我们的方式乃至会调用大家承继的方式 。但当你要想绕开这一调用体制呢?假定大家要想撰写Circle类的一个派生类来解决按某一因素放缩圆。为了更好地保证这一点，我们可以撰写类:

class ScalableCircle extends Circle {
    get radius() {
        return this.scalingFactor * super.radius;
    }
    set radius() {
        throw new Error("ScalableCircle radius is constant."  
                        "Set scaling factor instead.");
    }

    // Code to handle scalingFactor
}

留意，radius getter应用super.radius。这一新的super关键词容许大家绕开我们自己的特性，并从人们的原形逐渐找寻特性，进而绕开大家很有可能做了的一切调用。

父类特性浏览(顺带说一下，super[expr]还可以正常的应用)能够在一切用方式界定英语的语法界定的涵数中应用。尽管这种变量能够从初始目标中提炼出去，但浏览是关联到方式最开始界定的另一半上的。这代表将super方法取值给静态变量中始终不变super`的个人行为。

var obj = {
    toString() {
        return "MyObject: "   super.toString();
    }
}

obj.toString(); // MyObject: [object Object]
var a = obj.toString;
a(); // MyObject: [object Object]

派生类的内嵌指令

你很有可能想要做的另一件事是为JavaScript语言表达内嵌程序流程撰写拓展。内嵌的算法设计为该语言表达加上了很大的作用，可以建立运用这个作用的新种类是十分有效的，而且是派生类设计方案的基本一部分。假定您要想撰写版本管理二维数组。你应该可以开展变更，随后递交他们，或是回退到之前上传的变更。迅速完成的一种方式是撰写Array的派生类。

class VersionedArray extends Array {
    constructor() {
        super();
        this.history = [[]];
    }
    commit() {
        // Save changes to history.
        this.history.push(this.slice());
    }
    revert() {
        this.splice(0, this.length, this.history[this.history.length - 1]);
    }
}

VersionedArray的案例保存了一些关键的特性。他们是Array的真正案例，包含map、filter和sort。Array.isArray()会像看待二维数组一样看待他们，他们乃至会得到自动升级的二维数组length特性。乃至，回到新二维数组的涵数(如Array.prototype.slice())将回到VersionedArray!

派生类构造方法

你也许早已注意到上一个实例的构造方法方式中的super()。究竟发生了哪些事?

在传统式的类实体模型中，构造方法用以复位类案例的一切內部情况。每一个派生类承担复位与其说关联的情况。大家想要将这种启用连接起來，便于派生类与他们所拓展的类共享资源一样的复位编码。

为了更好地启用父类的构造方法，大家再度应用super关键词，这一次它如同一个涵数一样。此英语的语法仅在应用extends的类的构造方法方式中合理。应用super，我们可以调用Shape类。

class Shape {
    constructor(color) {
        this._color = color;
    }
}

class Circle extends Shape {
    constructor(color, radius) {
        super(color);

        this.radius = radius;
    }

    // As from above
}

在JavaScript中，大家偏向于撰写对this目标实现使用的构造方法，设定特性并复位內部情况。一般，this目标是在应用new启用构造方法时构建的，如同在构造方法的prototype特性上应用Object.create()一样。殊不知，一些内嵌目标有不一样的內部目标合理布局。比如，二维数组在存储空间中的空间布局与一般目标不一样。由于大家期望可以承继这种内嵌目标，因此 大家让最主要的构造方法（最上一级的父类）分派this目标。假如它是内嵌的，大家会获得大家要想的目标合理布局，假如它是一般构造方法，大家会获得this目标的初始值。

很有可能最惊讶的結果是在派生类构造方法中关联this的方法。在运作基类构造方法并容许它分派this目标以前，大家不容易有着this值。因而，在派生类构造方法中，在启用父类造涵数super()以前对this的全部浏览都将造成 ReferenceError。

如同我们在上一篇文章中见到的，你能省去构造方法方式constructor，派生类(派生类)构造方法还可以省去，如同你写的:

constructor(...args) {
    super(...args);
}

有时候，构造方法不与this目标互动。反过来，他们以其它方法创建对象，复位它，随后立即回到它。如果是这些状况，就沒有需要应用super。一切构造方法都能够立即回到一个目标，与是不是启用过父类构造方法（super）不相干。

new.target

让最上一级的父类分派this目标的另一个怪异的不良反应是，有时候最上一级的父类不清楚要分派哪一种目标。假定你已经撰写一个目标架构库，你要想一个基类Collection，它的一些派生类是Arrays，一些是Maps。随后，在运作Collection构造方法时，您将没法分辨要建立哪一种种类的目标!

因为大家可以承继父类的内嵌特性，在我们运作父类内嵌构造方法时，大家早已在內部知道初始类的prototype。沒有它，大家就没法建立具备适度实例方法的目标。为了更好地处理这类古怪的Collection难题，大家增加了英语的语法，便于将该信息公示给JavaScript编码。大家增加了一个新的元特性new.target，它相应于用new立即启用的构造方法。启用应用new启用的涵数会设定new.target为被启用的涵数，并在该涵数中启用super分享new.target的值。

这难以了解，因此我来告诉你您是什么意思:

class foo {
    constructor() {
        return new.target;
    }
}

class bar extends foo {
    // This is included explicitly for clarity. It is not necessary
    // to get these results.
    constructor() {
        super();
    }
}

// foo directly invoked, so new.target is foo
new foo(); // foo

// 1) bar directly invoked, so new.target is bar
// 2) bar invokes foo via super(), so new.target is still bar
new bar(); // bar

大家早已解决了上边叙述的Collection的难题，由于Collection构造方法能够只查验new.target,并应用它来派生类承袭，并明确要采用哪一个内嵌构造方法。

new.target在一切涵数上都是合理的，假如涵数并不是用new启用的，它将被设定为undefined。

十全十美

很多人 都直言不讳地表明，在语言表达特点中撰写承继是不是一件好事。你也许觉得，与旧的原形实体模型对比，承继始终比不上组成创建对象（composition）好，或是新英语的语法的干净整洁不值因而而欠缺设计方案协调能力。毫无疑问的是，在建立以可拓展方法共享资源编码的另一半时，mixin早已成为了一种关键的习惯用法，这也是有缘由的：他们带来了一种简易的方式 ，能够将不有关的源代码共享资源到同一个目标，而不用了解这两个不有关的一部分

在这个话题讨论上面有不一样建议，但我觉得有一些事儿特别注意。最先，做为一种语言表达特点加上的类并沒有强制性应用他们。第二，一样关键的是，将类做为一种语言表达特点加上并不代表他们一直处理承继难题的最好方式!实际上，有一些难题更适宜应用原形承继开展模型。在一天完毕的情况下，课程内容仅仅教會你能采用的另一个专用工具;并不是唯一的专用工具，也不一定是较好的。

假如想要再次应用mixin，你也许期待你能浏览承继了好多个物品的类，那样你便能够承继每一个mixin，让一切都很好。悲剧的是，如今变更承继实体模型会很不融洽，因而JavaScript沒有为类完成多种承继。换句话说，有一种混和解决方法容许mixin在根据类的结构中。根据大家都知道的mixin extend习惯用法，考虑到下面的涵数。

function mix(...mixins) {
    class Mix {}

    // Programmatically add all the methods and accessors
    // of the mixins to class Mix.
    for (let mixin of mixins) {
        copyProperties(Mix, mixin);
        copyProperties(Mix.prototype, mixin.prototype);
    }
    return Mix;
}

function copyProperties(target, source) {
    for (let key of Reflect.ownKeys(source)) {
        if (key !== "constructor" && key !== "prototype" && key !== "name") {
            let desc = Object.getOwnPropertyDescriptor(source, key);
            Object.defineProperty(target, key, desc);
        }
    }
}

如今我们可以应用mix涵数来建立一个复合型基类，而不要在各种各样mixin中间建立显式的承继关联。想像一下，撰写一个合作编辑工具，在其中记载了编写实际操作，而且必须对其信息开展实例化。你能应用mix涵数来撰写一个类DistributedEdit:

class DistributedEdit extends mix(Loggable, Serializable) {
    // Event methods
}

这也是十全十美的计划方案。非常容易见到怎样拓展这一实体模型来解决自身有超类的mixin类:我们可以简易地将父类传送给mix，并让回到类拓展它。