Зачем использовать наследование стиля ООП на основе классов в JavaScript? - PullRequest
5 голосов
/ 05 мая 2009

Если я не совсем ошибаюсь, каждый фреймворк / библиотека / подход в javascript сегодня склонен имитировать наследование стилей ООП на основе классов. Кажется, это объясняется тем, что люди думают, что наследование ООП на основе классов гораздо проще понять, и что большинство программистов знают ООП.

По своему опыту я не нахожу доказательств ни для одного из этих мнений. Я думаю, что наследование прототипов javascript просто прекрасно (и я сомневаюсь в целесообразности навязывания другой парадигмы языку, чем тот, на котором он построен). Большинство разработчиков, с которыми я встречаюсь, тоже не так хороши в классическом ООП. Так каковы причины выбора классического наследования в стиле ООП вместо наследования прототипа?

Ответы [ 8 ]

6 голосов
/ 05 мая 2009

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

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

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

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

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

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

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

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

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

4 голосов
/ 05 мая 2009

Мне кажется, что вы уже знаете ответ на свой вопрос, потому что вы указали его часть, когда сказали

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

Ни одна парадигма не является более правильной, чем другая, для решения проблемы. Я полагаю, что основная причина в том, что в наши дни всех учат ООП через Java. Поэтому, когда люди сталкиваются с ООП, они думают «о классах», потому что это то, с чем они знакомы. И всякий раз, когда они хотят решить проблему, они, скорее всего, будут использовать то, что знают.

Я бы также сказал, что программисту не выгодно использовать парадигму, с которой он не знаком. Большинство из нас должны использовать javascript для веб-разработки на стороне клиента и использовать язык ООП на основе классов на сервере. Лично я не хотел бы, чтобы такое ООП-несоответствие имело место, когда мне приходилось смотреть на сторону javascript приложения.

На определенном уровне тот факт, что каждый пытается реализовать ООП на основе классов в javascript, является образовательной проблемой. На другом уровне это психологический.

3 голосов
/ 29 октября 2009

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

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

3 голосов
/ 05 мая 2009

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

1 голос
/ 05 мая 2009

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

0 голосов
/ 05 мая 2009

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

0 голосов
/ 05 мая 2009

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

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

...