时间戳

首页 > 解决方案 > 就 JavaScript 引擎而言，实现原型委托而不是基于类的继承是否有好处？

javascript - 就 JavaScript 引擎而言，实现原型委托而不是基于类的继承是否有好处？

问题描述

查看带有类的现代 JavaScript，我的理解是，这都是覆盖在 ECMAScript2015 之前使用的基于原型的相同对象模型的所有语法糖。我喜欢直接使用原型链，但类肯定更容易。

所以在我看来，在 JavaScript 中，程序很可能都根据基于类的语法指定，但很可能根据原型对象的规则执行。因此，在 JavaScript 的编写方式和执行方式之间总是需要进行某种转换。

不管 JavaScript 是如何通过浏览器和其他引擎实现的，我的问题是：

从编写 JavaScript 引擎的角度来看，在原型委托而不是类方面实现面向对象的语言是否有性能或其他好处？

==== 编辑

一个类似的问题（基于原型的语言的 Hidden-class implementation）有评论表明传统意义上的类更容易在编译器级别实现，因为它们可以静态布局在内存中（我认为无论如何都是隐含的），但是这不允许动态结构，例如 JavaScript 允许的。所以在我看来，原型委托可能非常适合在编译器级别实现动态对象？

标签： javascript

解决方案

另一个角度是对象组合。

考虑一下：

class X { method() {} }
class Y extends X { method2() {} }

const y = new Y();

现在，在“经典”OOP 中，y它将是一个对象，它有两个方法，method并且method2.

在原型（经典 JavaScript）意义上，y是一个对象。该对象本身没有任何东西，但在它的原型上，它有一个method2. 第一个在哪里method？好吧，如果你深入挖掘原型的构造函数，你会发现它也有一个原型，其中method有一部分。

从节点 REPL 复制粘贴：

> class X { method() {} }
undefined
> class Y extends X { method2() {} }
undefined
> const y = new Y();
undefined
> y
Y {}
> y.prototype
undefined
> y.__proto__
Y {}
> y.__proto__.constructor
[Function: Y]
> y.__proto__.constructor.__proto__
[Function: X]

你需要能够支持那些对事物原型进行猴子补丁的人：

> X.prototype.method = () => console.log('I am here now!');
[Function]
> y.method();
I am here now!

推荐阅读