基于原型继承的语言中的类使用

class use in a prototypal inheritance-based language

本文关键字:语言 继承 于原型 原型      更新时间:2023-09-26

以下对这个问题的回答很好地解释了classical inheritanceprototypal inheritance之间的差异。 这让我很感兴趣,因为我开始用Java工作,但转向Javascript。

在他的回答中,他prototypal inheritance说,"所有关于课程的事情都消失了。如果你想要一个对象,你只需要写一个对象。

然而,关于如何在Javascript中"编写类"的文档和问题太多了。

为什么有推动力使语言成为它不是的东西。我正在寻找在这种原型语言中使用 JS 应用程序中的类更明智的具体示例,以及笨拙地将方形钉子放入圆孔的好处。正如 Aravind 所说,为什么人们通过与其他人进行比较来学习 Javascript,而不是按照它的意图......为什么这种做法似乎受到鼓励?

底线问题:为什么在 ECMAScript 6 中引入类?

群众喜欢阶级。

原型遗传没有什么"更多"或"更少"的自然,这完全是主观的。JS是它自己的语言,就像Smalltalk和Self对对象的含义有不同的想法一样。

ES6 类是句法糖。它们规范化/清理了如何在 JS 中使用继承/等。

与CoffeeScript类似,他们试图标准化OOP在JS中的完成方式,并使不习惯原型继承的人更熟悉它。

为什么人们通过与其他人进行比较来学习Javascript,而不是 如初意?

这涉及到认知和学习理论,但简短的版本是人类喜欢熟悉的事物,我们学习的方法之一是将新想法与我们已经拥有的知识联系起来。

为什么在 ECMAScript 6 中引入类?

实际上,类几乎是在 ECMAScript 4 中引入的。 我认为有很好的论据证明OOP是编写复杂软件的有用模式,并且基于类的继承比基于原型的继承更熟悉。 我认为一个同样有效的问题可能是"为什么JavaScript仍然实现基于原型的继承,而大多数学习它的人会更习惯基于类的继承?

如果你好奇 JavaSCript 中的类可能是什么样子,可以看看 ActionScript 3,它基于 EMCAScript 4 的草稿,具有基于类的继承。

当然,仅仅因为 ECMAScript 增加了类支持并不意味着 JavaScript 会,或者至少它很快就会

我发现Zakas的这篇文章清楚地解释了它,它只是语法糖,在一天结束时,Javascript将以同样的方式工作。

不用担心必须学习课程或不得不改变编程风格,什么都不会改变。 :)

为什么在 ES6 中引入类?糖,句法品种。

类对于

从面向对象语言(如Java)来到JavaScript的人非常有用。

这是我已经多次获得的经验。我有许多J2EE Web项目,拥有优秀的Java开发团队,他们有一些JavaScript知识,但并不多。我做的第一件事几乎就是解释原型、原型继承以及如何使用原型实现 OOP 范式——基本上是伪经典继承。(现在我几乎在每个此类项目中都会定期举办"Java 开发人员的 JavaScript"研讨会。

通过这种方法,我主要看到好的代码出来了。大多数Java开发人员倾向于坚持伪经典模式,并且对此非常满意。这很可能不是JS忍者会写的,但是,坦率地说,我不在乎。代码易于理解和维护,人们有良好的学习曲线,工作效率非常快。

原型语言,如JavaScript,对于不需要大量测试或维护的小规模短期项目来说非常有用。它们简单灵活的功能在这个领域确实大放异彩。

另一方面,基于类的语言往往更僵化,需要更多的设置,这在小东西上不是那么好,但额外的结构有助于保持更大的长期项目的可扩展性和可管理性。

当JavaScript刚开始时,它的主要功能是操作静态DOM元素,这对于原型语言来说是一个很好的应用程序。快速、灵活、简单 - 无需大惊小怪。然而,现在,JavaScript 所扮演的角色要复杂得多,并且越来越像一个应用程序而不是一个简单的脚本。向原型语言添加类听起来确实有点好笑,但是添加的结构类以及它们的广泛熟悉可以很容易地帮助开发团队处理现代JavaScript应用程序的复杂性。