JavaScript中的类

不是说 JS 的类有问题，但是如果你使用该语言已有一段时间，特别是使用过ES5，那么你可能就知道了从原型继承到当前类模型的演变。

原型链会有什么问题?

以我的拙见，这个问题的答案是：没有。但是社区花了很多年的时间才将类的概念强加到不同的结构和库中，因此ECMA技术委员会决定无论如何都要添加它。

你会问，这有什么问题吗?这就是他们真正做的，在我们已经拥有的原型继承之上添加了一些构成，并决定将其称为类，这反过来又让开发人员认为他们正在处理一种面向对象的语言，而实际上它们并不是。

类只不过是语法糖

jS 没有完全的 OOP 支持，它从来没有，这是因为它从来都不需要它。

表面上，当前版本的类显示OOP范例，因为：

• 我们可以创建基本的类定义，用非常经典的语法将状态和行为分组在一起。
• 我们可以从一个类继承到另一个类。
• 我们可以在公有和私有之间定义属性和方法的可见性(尽管私有字段仍然是一个实验性的特性)。
• 我们可以为属性定义getter和setter。
• 我们可以实例化类。

那么为什么我说类是语法糖呢?因为尽管在表面上，它们看起来是非常面向对象的，但是如果我们试图做一些超出它们可能的事情，比如的示例中，关键部分应该是applyMixins函数。如果，你没有完全理解它试图做什么，但可以清楚地看到它正在访问所有类的原型属性来复制和重新分配方法和属性。这就是我们需要看到真相的地方:类只不过是在经过验证的原型继承模型之上的语法糖。

这是否意味着我们应该停止使用类?当然不是，重要的是要理解它，而且如果我们想做些突破类的限制，那么我们就必须用原型来处理。

JS 的OOP 模型缺失了什么呢?

如果我们当前的OOP模型是如此之薄，仅是原型继承的抽象层，那么我们到底缺少什么呢?是什么让JS真正成为OOP?

看这个问题的一个好方法就是看看TypeScript在做什么。该语言背后的团队通过创建一些可以翻译成JS的东西，无疑将 JS 推向了极限。这反过来也限制了它们的能力。

目前 JS 中缺失的一些OOP构造具有内在的类型检查功能，在动态类型语言中没有真正的意义，这可能是它们还没有被添加的原因。

（编辑：东莞站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!