Почему использовать основанное на классе наследование стиля ООП в JavaScript?

Долгое время я считал ООП на основе прототипов слабой, плохой и неправильной версией ООП на основе классов. Затем, после того, как критическое количество информации просочилось в мою голову, я теперь понимаю ООП более абстрактно и нахожу оба способа приемлемыми в целом.

Я думаю, что ответ на ваш вопрос - большинство программистов гораздо лучше знакомы с ООП на основе классов, чем на основе прототипов.

На самом деле я бы сказал, что большинство не верит, что вы можете это сделать. есть объекты без классов.

обратите внимание, что даже если вы спорите об ООП на основе прототипов, вы называете его «прототипом», а ООП на основе классов - просто «ООП». Итак, вы сами страдаете от этого смещения, думая, что ООП => классы, прототипы => что-то еще.

и, поскольку большинство людей считают, что ООП - это правильный путь , независимо от проблемы, тогда прототипы должны быть уступает.

поэтому, чтобы ответить на ваш вопрос, есть два фактора:

1. плохое определение: «ООП => классы»
   • пропаганда: «это должно быть ООП, или вы не достойны»

, поскольку вы все еще ограничены первым, вы пытаетесь объяснить, что прототипы являются исключением из второго. Гораздо проще их исправить:

1. есть много способов сделать объекты, классы - самый простой для статических языков. Большинство людей учат программировать на статических языках, и большинство из них стараются использовать любой язык, такой же, как первый, который они выучили.

   • Есть много способов структурировать решение для программирования, ООП хороши в одних и паршивы в других.

Когда я писал свои первые сценарии, было круто и удобно иметь такой простой язык. Но сегодня вы не просто хотите переключать цвет кнопок, вы хотите создавать сложные приложения на JavaScript. Другие могут захотеть использовать ваше популярное приложение и хотели бы, чтобы сообщество предоставило плагины.

Теперь, с ООП это реализовать гораздо проще, особенно потому, что многие программисты знакомы с концепциями ООП.

Я бы сказал, что сам язык вводит людей в классическое мышление с его выбором" нового "в качестве ключевого слова и введением понятий как «конструкторы» в спецификации языка. В некотором смысле это ограничение - представьте себе изменение мышления, если вместо этого у нас было ключевое слово clone, и концепция черт ala SELF.

Одна из причин может заключаться в том, что ваша сторона сервера, вероятно, будет OO (ASP.NET, Java и т. Д.), Поэтому проще представить такую ​​же парадигму на клиенте. Не обязательно лучше , но легче.

Так каковы причины выбора классического наследования в стиле ООП вместо прототипного? На самом деле, я считаю, что некоторые фреймворки представляют собой своего рода комбинированные подходы. Возьмем, к примеру, шаблон наследования паразитной комбинации. Это то, что делает 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

И, конечно, если вы обращаете внимание на мои литералы, вы видите : Nicholas Zakas, парень, от которого я получил это;) Большая победа для этого: instanceof работает (некоторые говорят, и я вроде как согласен); экземпляры не разделяют состояние на ссылочных типах, таких как массивы (большой плюс!); родительский конструктор вызывается только один раз (что немаловажно!).

Кстати, здесь у меня есть примеры большинства популярных шаблонов наследования: Мои примеры TDD JS