为什么在javascript中使用基于类的OOP风格继承？

如果我没有完全错的话，那么现在javascript中的每个框架/库/方法都倾向于模仿基于类的OOP风格继承。原因似乎是人们认为基于类的OOP继承更容易理解，而且大多数程序员都知道OOP

---

根据我的经验，我找不到支持这两种观点的证据。我认为javascript原型继承很好（我怀疑在一种语言上强制使用另一种范式而不是它所基于的范式是否有用）。我遇到的大多数开发人员在经典OOP方面也不是很好。那么，选择经典OOP风格继承而不是原型继承的原因是什么呢？

我想答案在你的问题中——大多数程序员对基于类的OOP比对基于原型的OOP更熟悉

---

事实上，我甚至可以说，大多数人不相信没有类就可以拥有对象。

当我编写第一个脚本时，拥有这样一种简单的语言是很酷和方便的。 但今天，您不仅希望切换按钮颜色，还希望用JavaScript构建复杂的应用程序。其他人可能喜欢使用您的流行应用程序，并希望看到s社区提供插件

---

现在，使用OOP实现这一点要容易得多，特别是因为许多程序员都熟悉OOP概念。

一个原因可能是，您的服务器端可能是OO（ASP.NET、Java等），因此在客户机上使用相同的范例更容易思考。不一定更好，但更容易。

请注意，即使您支持基于原型的OOP，您也可以将其称为“原型”，而基于类的OOP只是“OOP”。因此，您自己也会受到这种偏见的影响，认为OOP=>类、原型=>其他东西

既然大多数人认为OOP是正确的方式，不管问题是什么，那么原型肯定是次等的

所以，要回答你的问题，有两个因素：

错误的定义：“OOP=>classes”

• 宣传：“一定是OOP，否则你不配”

因为你仍然受到第一个的限制，你试着解释原型是第二个的一个例外。更容易纠正的是：

处理对象的方法有很多，对于静态语言来说，类是最简单的方法。大多数人被教导使用静态语言编程，他们中的大多数人尝试使用任何语言，就像他们第一次学习的语言一样

• 有很多方法可以构造一个编程解决方案，OOP在某些方面很好，在另一些方面很糟糕

---

我认为，语言本身通过选择“new”作为关键词，并在语言规范中引入“constructor”等概念，引导人们进入经典思维模式。在某种程度上，这是一种限制——想象一下，如果我们有一个克隆关键词和自我的概念，心态会发生什么变化

我觉得你好像已经知道你的问题的答案了，因为你说的时候说了一部分

原因似乎是人 基于类的面向对象继承思想 更容易理解，而且 大多数程序员都知道OOP

在解决问题方面，两种范式都不比另一种更正确。我相信主要原因是现在每个人都通过Java学习OOP。因此，当人们遇到OOP时，他们会想到“oh类”，因为这是他们所熟悉的。每当他们想解决一个问题时，他们很可能会使用他们所知道的

我还要声明，对于程序员来说，使用他不熟悉的范例是没有好处的。我们大多数人必须使用javascript进行客户端web开发，并在服务器上使用基于类的OOP语言。我个人不希望每当我必须查看应用程序的javascript端时OOP阻抗不匹配

---

在某种程度上，每个人都试图在javascript中实现基于类的OOP这一事实是一个教育问题。在另一个层面上，这是一个心理问题。

很长一段时间以来，我认为基于原型的OOP是基于类的OOP的软弱、糟糕和错误的版本。然后，在大量信息泄漏到我的脑海中之后，我现在以更抽象的方式理解OOP，并发现这两种方式在总体上都是可以接受的

那么，选择经典OOP风格继承而不是原型继承的原因是什么呢？ 实际上，我相信有些框架是“某种”组合方法。以寄生组合继承模式为例。这就是YAHOO.lang.extend正在做的事情

它使用原型继承和助手函数来继承原型和构造函数。哇，听起来很复杂……是的，这是我的实现和测试，例如：

// Prototypal Inheritance
Object.prototype.inherit = function(p) {
    NewObj = function(){};
    NewObj.prototype = p;
    return new NewObj(); 
};

// Paraphrasing of Nicholas Zakas's Prototype Inheritance helper
function inheritPrototype(subType, superType) {
    var prototype = Object.inherit(superType.prototype);
    prototype.constructor = subType;
    subType.prototype = prototype;
};
function SubType(name, age) {
    Parent.call(this, name);
    this.age = age;    
};
inheritPrototype(SubType, Parent);  
SubType.prototype.getAge = function() {
    return this.age;
};

我对此代码进行了测试：

   describe 'Parisitic Combination Inheritance'
 it 'should use inheritPrototype (to call parent constructor once) and still work as expected'
     sub = new SubType("Nicholas Zakas", 29)
     sub.toString().should.match /.*Nicholas Zakas/
     sub.getAge().should.eql 29
     charlie = new SubType("Charlie Brown", 69)
     charlie.arr.should.eql([1,2,3])
     charlie.arr.push(999)
     charlie.arr.should.eql([1,2,3,999])
     sub.arr.should.eql([1,2,3]) 
     sub.should.be_an_instance_of SubType
     charlie.should.be_an_instance_of SubType
     (sub instanceof SubType).should.eql true 
     (sub instanceof Parent).should.eql true 
 end
    end

当然，如果你注意我的文字，你会看到：尼古拉斯·扎卡斯，我从他那里得到这个的人；）这一次的重大胜利是：instanceof works（有人说这很重要，我也有点同意）；实例不共享数组等引用类型的状态（一个大问题！）；父构造函数只调用了一次（一个大家伙！）

---

顺便说一句，我这里有很多流行继承模式的例子：

我遇到的大多数开发人员都不太擅长原型和oop。所以这只是你先学什么的问题。而且我也不会试图把它变成另一种语言。我同意大多数人认为类需要有对象。但是javascript也有它。名称完全不同；）这正是我不明白的。当然，如果你们都同意大多数开发人员比我更熟悉OOP的话。但是，是什么让OOP比原型方法更强大呢。我自己觉得“超级”被高估了。那么还有什么呢？不，你可以将数据序列化/整理成某种中间格式。解开不同的东西不是问题。即使您在客户端和服务器上有相同的行为