Question

在凯尔·辛普森（Kyle Simpson）的 You-Don't-Know-Js 丛书中，同时在 this＆Object Prototypes 的丛书中讨论了ES6之前的javascript中的类模式实现。他在第4章中提到了他称之为 pseudo-polymorphism 的系列。

他描述了这种伪多态性：

但是由于JavaScript的特殊性，显式的伪多态性（由于有阴影！）会在需要这种（伪）多态引用的每个函数中创建脆弱的手动/显式链接。这会大大增加维护成本。而且，虽然显式伪多态可以模仿“多重继承”的行为，但只会增加复杂性和脆弱性。

根据我的理解，这种伪多态性是一种不良行为，我们最好避免，因为它明确调用了 SUPER 类，就像他关于调用 Vehicle 的示例一样em> Car 类内部的em>类，因此我们将其作为这样的显式调用来实现：

function Car () {
    Vehicle.call( this );
}
//also overriding Vehicle's methods
Car.prototype.methodName = function( p1 ) {
    //manipulate p1 then call the super method. 
    Vehicle.prototype.methodName.call( this, p1 );
};

但是我想知道这里的问题是否与显式使用 Vehicle 类名有关，那么为什么我们不这样做：

function Car () {
    this.super = Object.getPrototypeOf( this ).constructor;
    this.super.call( this );
}
//also overriding Vehicle's methods
Car.prototype.methodName = function( p1 ) {
    //manipulate p1 then call the super method. 
    this.super.prototype.methodName.call( this, p1 );
};

不是在解决问题的其他面向类语言中伪造或模仿了 super 关键字吗？

Answer 1

...为什么我们不只是这样做...

因为它不起作用，但是您距离第一个跌倒陷阱的人很远。 :-)尝试添加LuxuryCar的{{1}}子类以查看问题：现在，Car（即使在this.super代码中）引用的是Car，而不是{{ 1}}。

有些模式可以避免在ES5级代码（I wrote one of them up in 2009）的Car中显式使用名称Vehicle，但现在已经过时了；相反，我们使用ES2015中的Vehicle语法（必要时进行编译）：

Car

Javascript：类设计模式-伪多态性

1 个答案: