为什么基于类的 OO 而不是基于原型的 OO 如此受欢迎？他们在学校教后者吗？尽管 Javascript 是基于原型的，但大多数人主要是在功能上使用它，或者通过尝试模拟基于类的系统的框架来使用它。
我知道 Sun 对Self进行了一些研究- 还有其他关于基于原型的 oo 的知识来源吗？最好是可以自学的东西。
我找到了一本书，其中包含已发表的论文：基于原型的编程：概念、语言和应用程序
有人读过吗？
--
因此，我为给我最多的答案提供了赏金。不过，我并不是很满意。我希望听到更多技术性的答案。也许我没有很好地解释自己。
原型继承的优势在于它可能允许以简单的方式进行花哨的元编程，因为原型链很容易操作。这是一个相当学术的优势，因为元编程在 99% 的情况下都是错误的答案。例如，您可以拥有一个带有特殊 DSL 的 Javascript Key-Value Observer 样式的数据操作层，该层在离线时通过原型交换在本地 SQLite 支持和在线时基于 REST 的服务器存储之间透明地切换。我不确定这是不是最好的方法，但这是我这么晚能想到的最好的方法。这不是你通常想要在项目代码中做的那种事情，因为一旦你开始让它在多层上运行，这种间接的调试就很难了，但是当你将它保存在库中时它也不错。
另一个不太有用的优点是它允许您设计自己的类系统。我说不太有用，因为或多或少所有的 javascript 库都有自己稍微不兼容的方法来组合“类”。
有很多人在回答他们将继承模型与该模型中实现的语言混合在一起。javascript 是动态且弱类型的，因此难以工具化这一事实与它是一种原型语言无关。
如果您正在寻找有人指出每个人的优点/缺点作为对其受欢迎程度的解释，我认为您正在陷入一种谬误，出于某种原因，这种谬误在技术中非常普遍 - 受欢迎程度与某些人有关质量的绝对衡量标准。
事实要平淡得多——基于类的 OO 很受欢迎，因为 Java 使用经典的 OO，而 Sun 花费了数百万美元和很长时间来建立 Java 的普及——确保人们知道它已在公司中成功使用，在大学中广泛教授，以及高中 AP 考试。
原型/经典 OO 只是组织想法的不同方式。您可以用本机不支持它的语言来实现任何一个（想到Python和Java ，另一边是JavaScript ）。
在经典的 OO 中，您为对象定义类的抽象层次结构，然后实际使用这些类的实例。在原型继承中，您创建对象实例的层次结构。虽然我想这在两个阵营中可能有点异端，但我看不出你不能将两者混合的原因......
我不知道确切的原因，但这是我的原因
我认为这个争论与动态与静态相同，类是对象的静态定义，可以很容易地使用它来了解对对象的期望，它还有助于工具语言具有适当的智能感知支持和文档，因为你可以很容易地知道对象中有哪些不同的成员和方法，另一件事是能够在类中声明私有成员的不同范式，这些成员没有显示在对象上，这不能在原型中完成范例。
原型范例很好，但是它缺乏提供有关对象中的方法和成员的信息的能力，这使得工具变得更加困难，并且对于动态类型编程也更有意义。
这个问题让我很感兴趣，所以我回去阅读了一些关于这个概念的原始论文。它似乎始于 1980 年代中期的 Smalltalk 世界，但最终成为Self的创始负责人之一。很久以后 Javascript 也采用了它。
论文中提出的论点是它更容易学习。除了学习之外，确实没有提出任何技术上的好处。这些论文都解释了它如何与基于类的语言一样具有表达力，但更容易学习。人们自然而然地以具体的方式而不是抽象的方式思考事物。我们想到的是我们在动物园看到的大象，而不是一般的“大象”。当我们看到其他大象时，我们将它们归类为与第一只大象不同。基于原型的语言促进了这种思考。把它想象成微分编程。
这是在语言中使用它的充分理由吗？也许。自从这个想法开始渗透以来的 25 年里，我认为像基于类的 OO 这样的抽象概念对于大多数人来说并不太难学习。另一方面，也许需要一种更容易的蓝领编程语言（如 Javascript），这可能是实现这一目标的一种方式。
如果有兴趣，您可以从这篇关于自我的论文开始。
我真的不想再写一篇关于原型继承的文章了，所以我只是将你链接到我以前的文章。请注意，它们确实很长，但非常值得一读：
我认为不同之处在于为您提供的动力动态（原型）语言。Javascript 与 LISP 一样，为程序员提供了几乎无限的能力。这种权力只受程序员的责任和他的自信心水平的限制。所以讨论和它一样古老 - 与静态类型与无类型相同。如果你认为你的编程能力和自律性足够强，那就选择原型风格。
套用一句名言：
人才做他能做的（阅读：基于类），天才做他想做的（阅读：基于原型）。