基于原型的 OO 与基于类的 OO 相比有哪些优点？
为什么基于类的 OO 如此受欢迎，而不是基于原型的 OO？他们在学校教授后者吗？尽管 Javascript 是基于原型的，但大多数人主要是在功能上使用它，或者通过尝试模拟基于类的系统的框架。
我知道Sun对Self进行了一些研究 - 是否还有其他关于基于原型的OO的知识来源？最好是可以自学的东西。
我找到了一本书，其中包含已发表的论文：基于原型的编程：概念、语言和应用
有人读过吗？
——
所以我对给我最多的答案给予了赏金。尽管如此，我还是不太满意。我希望听到更多技术性的答案。也许我没有很好地解释自己。
Why is class based OO so popular instead of prototype based OO? Do they teach the latter in schools? Though Javascript is prototype based, most people use it mostly functionally, or via frameworks that try to emulate a class based system.
I know that Sun has had some research on Self - is there any other source of knowledge on prototype based oo? preferably something that is accessible for self learned.
I found a book that contains published papers: Prototype-Based Programming: Concepts, Languages and Applications
Has anyone read it?
--
So I gave the bounty for the answer that gave me most. Still, I'm not really satisfied. I would have liked to hear much more techical answers. Maybe I didn't explain myself well.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
原型继承的优点是它可能允许以简单的方式进行花哨的元编程，因为原型链很容易操作。这是一个相当学术性的优势，因为元编程在 99% 的情况下都是错误的答案。例如，您可以拥有一个带有特殊 DSL 的 Javascript Key-Value Observer 风格的数据操纵层，该层可以通过原型交换在离线时的本地 SQLite 支持和在线时基于 REST 的服务器存储之间透明地切换。我不确定这是最好的方法，但这是我这么晚能想到的最好方法。这不是你通常想要在项目代码中做的事情，因为一旦你开始在多层上进行这种间接的调试，调试起来就很困难，但是当你将它保存在库中时，它也不错。
另一个不太有用的优点是它允许您设计自己的类系统。我说没那么有用，因为或多或少所有的 javascript 库都有自己的稍微不兼容的方法来组合“类”。
有很多人回复说他们将继承模型与该模型中实现的语言混合在一起。 JavaScript 是动态的、弱类型的，因此很难使用工具，这一事实与它作为一种原型语言无关。
The advantage of prototypal inheritance is that it potentially allows fancy metaprogramming in a straightforward way because the prototype chain is easily manipulated. This is a rather academic advantage because metaprogramming is the wrong answer 99% of the time. As an example, you could have a Javascript Key-Value Observer style data manipulation layer with a special DSL that transparently switched between a local SQLite backing when offline and a REST based server store when online via prototype swapping. I'm not sure it's the best way to do this, but it's the best I can come up with this late. It's not the sort of thing you generally want to do in project code since this sort of indirection is hell to debug once you start getting it going on multiple layers, but it's not bad when you keep it in a library.
Another less helpful advantage is that it allows you to design your own class system. I say less helpful because more or less all javascript libraries have their own slightly incompatible approach to how 'classes' are put together.
There are a lot of people replying who are mixing the inheritance model with the languages implemented in that model. The fact that javascript is dynamic and weakly typed and thus hard to tool has nothing to do with it being a prototypal language.
如果您正在寻找某人指出每种技术的优点/缺点来解释它们的受欢迎程度，我认为您陷入了一个谬论，由于某种原因，这种谬论在技术中非常常见 – 受欢迎程度与一些绝对的质量衡量标准。
事实要平淡得多 – 基于类的 OO 之所以流行，是因为 Java 使用了经典的 OO，而 Sun 花费了数百万美元和很长时间来建立 Java 的流行 – 确保人们知道它在企业中得到了成功的使用，教授广泛应用于大学和高中 AP 考试。
原型/经典面向对象只是组织想法的不同方式。您可以使用本身不支持它的语言来实现其中之一（Python 和 Java 出现在我的脑海中，JavaScript 在另一边）。
在经典的面向对象中，您为对象定义类的抽象层次结构，然后实际使用这些类的实例。在原型继承中，您创建对象实例的层次结构。虽然我认为这在两个阵营中可能都有点异端，但我不认为你有理由不能将两者混合在一起......
If you're looking for someone to point out the advantages/disadvantages of each as an explanation for their popularity, I think you're falling for a fallacy which is for some reason very common in technology – that popularity has something to do with some absolute measure of quality.
The truth is a lot more bland – class-based OO is popular because Java uses classic OO, and Sun spent millions of dollars and a very long time building the popularity of Java – making sure people know it's used successfully in corporations, taught widely in universities, and on high school AP tests.
Prototypal/classical OO are just different ways of organizing your ideas. You can implement either one in languages that don't support it natively (Python and Java come to mind, and JavaScript on the other side).
In classical OO, you define an abstract hierarchy of classes for your objects, and then actually work with instances of those classes. In prototypal inheritance, you create a hierarchy of object instances. Although I imagine it might be a bit heretical in both camps, I don't see a reason you couldn't mix the two...
我不知道确切的原因，但
我认为这个争论与动态与静态相同，类是对象的静态定义，可以轻松地使用它来了解对对象的期望对象，它还有助于工具化语言以获得适当的智能感知支持和文档，因为您可以轻松地知道对象中的不同成员和方法是什么，另一件事是能够在类中声明私有成员的不同范式不显示在对象上，这是无法完成的在原型范式中。
原型范例很好，但是它缺乏提供有关对象中的方法和成员的信息的能力，这使得工具变得更加困难，并且对于动态类型编程也更有意义。
I don't know the exact reasons for this, but here are my reasons
I think this argue is the same as Dynamic vs Static, a class is the static definition of the object, that can be used easily to know what to expect from an object, it also helps tooling the languages to have proper intellisense support and documentation because you can easily know what are the different members and methods in the object, another thing is the different paradigm of having the ability to declare private members in the class that doesn't show on the object, this can't be done in the prototype paradigm.
The prototype paradigm is nice, however it lacks the ability for providing information about the methods and members in the object, which makes the tooling harder, and it also makes more sense for dynamic typing programming.
这个问题引起了我的兴趣，所以我回去阅读了一些关于这个概念的原始论文。它似乎始于 20 世纪 80 年代中期的 Smalltalk 世界，但最终成为 Self 的创始原则之一。很久以后 Javascript 也采用了它。
论文中提出的论点是它更容易学习。除了学习之外，实际上没有提出任何技术好处。这些论文都解释了它如何与基于类的语言一样具有表达能力，但更容易学习。人们自然会以具体的方式而不是抽象的方式思考事物。我们想到的是我们在动物园看到的大象，而不是一般的“大象”。当我们看到其他大象时，我们会将它们归类为与第一只大象的差异。基于原型的语言促进了这种思考。将其视为微分编程。
这是在语言中使用它的充分理由吗？也许。自这个想法首次出现以来的 25 年里，我认为像基于类的 OO 这样的抽象概念对于大多数人来说并不是太难学习。另一方面，也许需要一种更简单的蓝领编程语言（如 Javascript），这可能是实现这一目标的一种方法。
如果有兴趣，您可以从这篇关于自我的论文开始。
This question had me intrigued so I went back and read some of the original papers on the concept. It appears to have begun in the mid-1980s in the Smalltalk world but eventually became one of the founding principals of Self. Much later Javascript also adopted it.
The argument put forth in the papers is that it is easier to learn. There is really no technical benefit proposed other than learning. The papers all explain how it is just as expressive as a class-based language but much easier to learn. People naturally think about things in a concrete manner rather than in the abstract. We think of the elephant we saw at the zoo, not a generic "elephant". When we see other elephants, we classify them as differences from the first one. A prototype-based language facilitates this thinking. Think of it as programming by differential.
Is that a sufficient reason to use it in a language? Perhaps. In the 25 years since the idea first started percolating, I would argue that abstracted concepts like class-based OO has not been too hard for most people to learn. On the other hand perhaps there is a need for a blue-collar programming language (like Javascript) which is easier and this may be a way to accomplish that.
If interested, you might start with this paper about self.
http://en.wikipedia.org/wiki/Prototype-based_programming#Criticism我认为解释得很好。
http://en.wikipedia.org/wiki/Prototype-based_programming#Criticism explains it quite well I think.
我真的不想再写另一篇关于原型继承的文章，所以我只是将您链接到我之前的文章。请注意，它们确实很长，但非常值得一读：
I really don't want to write another article about prototypal inheritance again so I'll just link you to my previous articles. Mind you, they are really long but well worth the read:
我认为区别在于动态（原型）语言给你带来的力量。 Javascript 与 LISP 一样，为程序员提供了几乎无限的能力。这种权力仅受程序员的责任和自信心水平的限制。所以这个讨论很古老——就像静态类型与无类型一样。如果您认为自己的编程能力和自律性足够强，请选择原型风格。
套用一句名言：
天才做他能做的（阅读：基于阶级），天才做他想做的（阅读：基于原型）。
I think the difference is in the power dynamic (prototyped) language gives to you. Javascript, same like LISP, gives almost unlimited power to a programmer. This power is only limited by programmer's responsibility and the level of his self-confidence. So the discussion is as old as it is - same as static typing vs. typeless. If you consider your programming power and self-discipline are strong enough - go for prototyped style.
Paraphrasing one famous saying:
Talent does what he can (read: class-based), genius does what he wants (read: prototype-based).