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

[Kolyaj]

Просто я не видел пример "элегантного" наследования на прототипах, которое бы сохраняло функциональность конструктора родительского класса

Его просто не может существовать, т.к. наследуются не классы, а объекты.

[Dmitry A. Soshnikov]

Ясно, что реализация динамического классового ООП на JavaScript это то же прототипное ООП, вид сбоку.

Это не только вид сбоку, это 97% - то же самое, только в другой терминологии. Неназванная связка "конструктор + прототип" в JS - есть "ссылка на класс + класс" в Python'e.

Ну вот найди сильные отличия:

# python

class A(object):
  def __init__(self):
    self.a = 10

// аналог на JS

function A() {
  this.a = 10
}

x = A() # py
var x = new A(); // js

x.a # 10, py
x.a // 10, js

A.b = 20 # добавим новое свойство в класс, доступное всем инстансам
A.prototype.b = 20; // аналог на js

x.b # 20, py
x.b // 20, js

// Однако, свойство "b" не является родным для объектов "x"
// сделаем его родным

x.b = 30 # py
x.b = 30 // js

x.b # 30, py
x.b // 30, js

// Удалим родное свойство "b"

del x.b # py
delete x.b // js

// Снова, за счет делегации к классу (к цепи классов; в Питоне)
// и к прототипу (к цепи прототипов; в JS)
// доступно свойство "b"

x.b # 20, py
x.b // 20, js

// Более того, можно расширять класс / прототип через инстанс:

x.__class__.c = 30 # py
x.__proto__.c = 30 // js (__proto__ - спечифично для конкретной реализации, но - не суть)

x.c # 30, py
x.c // 30, js

// Наследование

# py

class B(A):
  def __init__(self):
    A.__init__(self)

// js

function B() {
  B.superclass.apply(this, arguments);
}

// блок, для вынесения в обертку (для улучшения code reuse, чтобы каждый раз не повторять одно и то же)

// одна из реализаций

var __inheritance = function () {};
__inheritance.prototype = A.prototype;
B.prototype = new __inheritance();
B.prototype.constructor = B;
B.superclass = A;

// при этом, конструктор может издохнуть после порождения
// объекта, и объект за счет своей (неявной) ссылки на прототип
// будет иметь доступ к прототипу

// аналогичная картина и Python'e:
// сслыка на класс - "А" - может издохнуть,
// но порожденный объект все еще будет иметь
// доступ к классу за счет ссылки на класс, включая явную - __class__

// примеры не привожу, здесь понятно.

Спорить по вопросу статика vs. динамика в рамках JavaScript, как я понимаю, бессмысленно. Поэтому мы говорим только о динамической модели.

Да мы и не спорим, мы рассуждаем. Просто когда говорят о "классовая модель", это может восприниматься как классы из статической модели. В то время, как, практически нет отличий в динамической классовой модели от прототипной (и в Python'e можно динамически менять классы (просто меняя ссылку __class__) и apply'ить (делегировать) к изначально несвязанным методам). Поэтому можно спросить: что такое "Практически все фреймворки стремятся к динамической классовой модели", если уже изначально практически отличий нет. Я вижу ответ, как - лишь добавить обертку для наследования, ну, и, может, добавить пару слотов для какого-нибудь еще синтаксического сахара. В принципе, это удобно.

[Андрей Параничев]

Dmitry A. Soshnikov,
Спасибо за разъяснения. Получается, что простая реализация наследования реализуется с избыточным кодом:

var __inheritance = function () {};
__inheritance.prototype = A.prototype;
B.prototype = new __inheritance();
B.prototype.constructor = B;
B.superclass = A;

Который рациональнее прятать в отдельную функцию. Получается, что это скорее "стандартный прием", чем простое упрощение.

что такое "Практически все фреймворки стремятся к динамической классовой модели", если уже изначально практически отличий нет.

Да это так, единственное отличие в том, что python получает ссылку на родительский класс "наглядно", а в JavaScript - конструкцией из 4х строк минимум.

Фреймворки и убирают этот момент, делая динамические классы:

var myClass = new Class({
    "extend": myParentClass,
    "constructor": function() { /* "конструктор" */ },
    "property": "value"
});

Я и хотел узнать, насколько такой подход необходим и насколько считается "плохим тоном", говоря о JavaScript. Получается, что такой вариант помогает убрать избыточность, которую порождает обычный подход конструктор-прототип. Хоть я и разобрался в наследовании на прототипах, но думал, что что-то упустил. Потому что не понимал, зачем во фреймворках используется "эмуляция классического ООП", а именно - вид динамического ООП на классах.

[Dmitry A. Soshnikov]

Я и хотел узнать, насколько такой подход необходим и насколько считается "плохим тоном", говоря о JavaScript.

Если человек понимает, что он делает и зачем (и это, действительно, технологически обосновано) - никакого плохого тона здесь нет. "Плохой тон" начинается тогда, когда человек начинает мыслить (в виду недостатка информации) о JS, как о "недоязыке, который даже языком не является, т.к. в нем нет классов". Но, если начинаются такие мысли, то, я думаю, такой человек смутно понимает и ООП на классах (да и программирование в целом).

Касательно же обертки - никакого плохого тона. Иначе "плохим тоном" можно было бы назвать и это:

for (var k = 0; k < 3; k++) {
  alert(k);
}

У нас есть повторяющийся кусок кода, мы его выносим в цикл. Можно было бы привести пример - выносим в функцию - не суть, то же самое.

Иначе:

alert(0);
alert(1);
alert(2);

Это, стало быть, не "плохой тон", т.к. мы не используем обертку для повторяющегося куска кода. Ну, да, code reuse методом copy-paste - очень "красивый" метод

[Zeroglif]

Я и хотел узнать, насколько такой подход необходим и насколько считается "плохим тоном", говоря о JavaScript.

А какой подход-то? Я вижу обычный вызов, в аргументе объект... давайте что ли в нутрь 'Class' посмотрим, чего там происходит против "стандартного" способа.

[Андрей Параничев]

Zeroglif,
Там ничего против, естественно, не происходит. Я просто хотел узнать насколько необходимо использование оберток в реализации наследования.

[Zeroglif]

Zeroglifнасколько необходимо использование оберток в реализации наследования.

Острой необходимости нет.

[Pavel_Volodko]

Вставлю свои "пять копеек"...

Основная суть данной темы - не красивость или какая-то верность принципам классического ООП. Просто классовое наследование может существенно облегчить жизнь при реализации сложных проектов.

Что я понимаю под классовым наследованием?

1. Возможность четкого определения принадлежности объекта классу (instanceOf)
2. Возможность вызова конструктора или любого метода базового класса

Это то, что хочется получить. Очевидно, что в JavaScript без "обёрток" не обойтись. Ну, а чем "элегантнее" и проще это будет сделано, тем лучше.

Кстати, интересно будет узнать ваше мнение, коллеги, по поводу моей "обёртки" (Классическое наследование в JavaScript).

Буду благодарен за любые отзывы

[Kolyaj]

Ну, а чем "элегантнее" и проще это будет сделано, тем лучше.

Че-та на простоту у вас не тянет.

[Pavel_Volodko]

Че-та на простоту у вас не тянет.

Вы про статью? Или про результат

var DerivedClass = function() {

    arguments.callee.$super.call(this);

}.$extends( BaseClass ).$class( function ($super) {

    this.someMethod = function () {
        return $super.someMethod.call(this);
    }

});

Что тут сложного? Вопрос серьёзный, т.к. мне интерестно узнать мнения разных людей.