"Классический" ООП в JavaScript
 

Несколько раз начинал писать этот пост, но в итоге решил не распинаться, а спросить коротко и ясно.

Используете ли вы эмуляцию "классического" ООП (с классами и наследованием на классах) в своих проектах, или пользуетесь конструкторами и наследованием на прототипах? Или вообще не пользуетесь наследованием?

Зависит от используемого фреймворка. В данный момент в основном Ext, соответственно и наследование через Ext.extend. Если что-то делается без фреймворка, то, как правило, и наследование не особо нужно.

Kolyaj,
Другими словами, если бы ты решал задачу уровня ExtJS, но без фреймворка, то реализовал бы классическую модель ООП?

Пожалуй задачу уровня ExtJS не то что без фреймворка, а с любым другим трудновато решить.

Давай определимся, чтобы не говорить о разном: что есть классическая модель ООП?

Чтобы более точно представить картину, надо понять, что, если говорить о разнице в подходах, то нужно говорить больше не о "класс vs. прототип" и даже не о "наследование vs. делегация", а в большей мере о "статика vs. динамика".

Я практически всегда для примера привожу классовую модель Python'a, чтобы показать, что разницы между "динамическим ООП на классах" и "ООП на прототипах" практически нет (если нужно будет привести примеры и показать сходство, скажите).

Что же касается статической классовой ООП модели (aka Java или C++), то ее просто физически нельзя сделать в JS (даже эмуляцию). Во сколько бы обертор мы не обернули бы конструкторы, внутри все равно будет prototype-base inheritance.

Единственное, для чего можно использовать обертки - это улучшение code reuse - вынос повторяющегося блока наследования (обеспечение связки прототипов) в обертку. Как потом эту обертку называют - "Class", "Extend", "Inherit" и т.д. - не суть важно, главное, чтобы человек понимал, что он делает. Другой вопрос, когда начинается непонимание технологии ввиду того, что человек не имеет достаточного объема информации и может доказывать то, что к JS не имеет никакого отношения. Часто причиной этому могут быть статьи с громкими заголовками типа "Наследование на классах в JS", которые подсознательно могут откладываться в умах людей, который пока поверхностно разбираются в JS, как "доведем до ума этот бесклассовый недоязык". Это уже неправильно.

А в целом - никто не ограничивает делать обертки (для улучшения code reuse'a) и называть как вздумается. У меня в одном проекте был виджет-фреймворк написан, где было построено наследование виджетов (aka Widget -> WidgetPanel -> WidgetWindow -> WidgetDialog и т.д.). Для чего я использовал там обертку? - Чтобы вынести в нее блок кода, обеспечивающий связку прототипов. Все. Объективно, это единственная причина, т.к. вся эта мишура с оберткой, могла бы быть описана и без нее - и без потери какой-либо читабельности и функциональности. Но мне было удобней с обреткой.

Поэтому, если анализировать различия, то, повторю, в большей мере надо говорить о "статика vs. динамика"; пара же "прототип vs. класс" очень больших отличий не покажет.

Kolyaj,
Ну это вопрос чисто теоретический. Скорее вопрос должен был звучать "если бы ты писал ExtJS, ты бы использовал эмуляцию классического ООП?".

Я по этим понятием подразумеваю описание классов и наследование, которое основывается на классах.

Так а че там? Сделали функцию-обертку для связывания прототипов, вот тебе и классическое ООП настолько, насколько это возможно и нужно в JavaScript.

Вот тебе и ООП с оберткой. "Классическое", "основанное на классах" - не стоит в противоположном углу, относительно "прототипное". Противопоставляется только динамика-статика.

Dmitry A. Soshnikov,
ну я в рамках предложенного определения

Dmitry A. Soshnikov,
Спорить по вопросу статика vs. динамика в рамках JavaScript, как я понимаю, бессмысленно. Поэтому мы говорим только о динамической модели. Ясно, что реализация динамического классового ООП на JavaScript это то же прототипное ООП, вид сбоку.

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

Kolyaj,
Ключевое слово - нужно, а без такой обертки не реализовать удобное наследование?

Просто я не видел пример "элегантного" наследования на прототипах, которое бы сохраняло функциональность конструктора родительского класса, выстраивала цепочку прототипов (для instanceOf) и правильно линковала constructor. И чтоб она была без прослойки.