Понимание ООП на джаваскрипте (ES5), часть 2

[NekR]

Я бы сказал, что уже скоро будет ES6 и все новые фичи ES5 уже не новые.

[spmbt]

Интересно было бы запустить опрос, какая доля разработчиков использует фичи ES5 в повседневных разработках. У меня такой мысли не было, потому что думаю, что весьма небольшая. Но добавил опрос для проверки этого мнения.

[NekR]

Очень прискорбно, что сейчас лидируют 2 последних пункта.

[Large]

В принципе ES5 поддерживается уже достаточно хорошо, и его уже можно использовать если забыть про всякие не важные мелочи и strict mode: kangax.github.io/es5-compat-table/

К сожалению ES6 будет доступен ещё не скоро.

[NekR]

Я уже года 2 использую es5 в продакшене, strict mode включён естественно. Где поддерживается, там хорошо, где нет, увы.

[monolithed]

Мне кажется, что тут забыли Object.create

[rock]

Первая часть статьи с него и начинается.

[MuLLtiQ]

Хм, я использую obj.constructor.prototype вместо Object.getPrototypeOf(obj). Это плохо?

[slayeek]

В вашем подходе все в порядке. Если интересны подробности, то посмотрите вот тут — tobyho.com/2010/11/22/javascript-constructors-and/

[termi]

Потому, что может быть obj.constructor.prototype != Object.getPrototypeOf(obj)

[rock]

Главное на грабли не наступать:

function F1(){};
F1.prototype = {
  prop1: 1,
  prop2: 2
}
obj1 = new F1;
console.log(Object.getPrototypeOf(obj1) == F1.prototype);    // true
console.log(obj1.constructor.prototype == F1.prototype);     // false - O_o
console.log(obj1.constructor.prototype == Object.prototype); // true
function F2(){}
function F3(){}
F3.prototype = new F2;
obj2 = new F3;
console.log(Object.getPrototypeOf(obj2) == F3.prototype);    // true
console.log(obj2.constructor.prototype == F3.prototype);     // false - O_o
console.log(obj2.constructor.prototype == F2.prototype);     // true

[MuLLtiQ]

Разумеется, ссылку constructor у прототипа надо править, иначе constructor созданного объекта будет указывать не на конструктор объекта а на конструктор прототипа. Видимо getPrototypeOf ввели, чтобы не париться по этому поводу, или просто для ясности.

[tenshi]

Как раз недавно запилил либу для множественного наследования: javascript.ru/forum/project/40210-jin-i-snova-o-nasledovanii.html

Множественное наследование — это безусловно классно, но есть ряд проблем:
1. Конфликты имён. Не должны методы одной примеси молча затирать методы другой. В моей либе вместо затирания происходит создания метода-конфликта. Чтобы разрешить конфликт нужно примешать такой метод в описании которого указано, что он пригоден для разрешения конфликта между теми конфликтующими методами.
2. Не всегда понятно какой метод/свойство взяты из какой примеси/класса. В моей либе каждый метод имеет глобальный идентификатор. А также есть функция которая раздаст идентификаторы уже готовой структуре объектов.
3. Зачастую нужен доступ ко всем перегруженным методам, а не только к методу одного последнего предка. В моей либе все когда либо примешанные методы сохраняются в прототипе по тому самому глобальному идентификатору.

По ссылке больше примеров)

[zandroid]

Не холивара ради, но множественное наследование говорит лишь о проблемах в обсерватории. Мне много где приходилось применять обычное наследование (одиночное, хоть на прототипах, хоть классическое), и много делал полезных примесей, которые придают объекту определённые «способности» (удачно подобранное выражени в статье). Но множественное наследование — это перебор. IMHO.

[tenshi]

И чем же множественное примешивание отличается от множественного наследования? х)

Я вот каких только вариантов повторного использования кода не перепробовал, но остановился на таком:
Есть типажи (штрихи/примеси/классы), они по умолчанию ничего не умеют.
Для типажей можно определять методы.
Типажи могут быть примешаны друг ко другу. При этом ранее определённые и позже определяемые в предках методы также копируются и в потомков каскадно.
В качестве типажей могут быть использованы любые глобально доступные объекты.
Каждый метод хранит информацию о том, какие методы он умеет перегружать.
Одноимённые методы определяемые в одном типаже проходят через процедуру «слияния».
Результатом «слияния» является либо один из методов (который должен уметь перегружать всех оставшихся), либо автоматически генерируемый метод-конфликт, хранящий в себе информацию о конфликтующих методах. Совсем как в системах контроля версий: типаж — это фичеветка.

[zandroid]

Множественное примешивание — это простая операция, которая не сохраняет информацию о перегрузках методов, она их просто перекрывает и всё. После примешивания вы не можете обратиться к источнику примеси (т.к. это не требуется), и не можете знать какой источник предпоследний и т.д. В общих словах, вы ориентируетесь на результат без истории его возникновения.

[tenshi]

Из пальца высосал разницу)
Ну и что хорошего в этаком примешивании? Скорость? Одинаково. Потребление памяти? Одинаково. Простота реализации? А толку от простоты, если она приводит к трудноуловимым багам? По твоему ловить глюки, вызванные конфликтом методов, лучше, чем вменяемое сообщение о конфликте? Или писать костыли, когда нужно не просто переопределить метод, а дополнить?

[zandroid]

Хорошего именно простота логики, не надо заботиться о что откуда почему пришло и как это себя поведёт если… Не стоит усложнять там, где это не требуется, и стоит упрощать там, где это возможно.

Я не спорю, что бывают задачи разные и разные подходы к их решению, и каждому унструменту свою задачу. Я высказал своё мнение, что я лучше разобью логику на более простые составляющие, чем буду применять «множественное наследование», и да, я считаю, что если это самое множественное наследование применяется повсеместно, то стоит пересмотреть подходы к проектированию/программированию.

Серебряной пули не существует, на этом давайте и закончим, и без того затянувшийся и слишком абстрактный разговор.

[tenshi]

Вот так вот не беспокоятся, а потом тратят на дебаг в 3 раза больше времени. Потому что беспокоиться о том что откуда пришло — необходимо. Потому, что нужно точно знать какие методы будут у объектов и как они будут действовать. Когда ты примешиваешь две пимеси, то у тебя возникает неопеделенность, которая сейчас работает как надо, а потом может сломаться. А находить такие баги довольно проблематично. Да и для разрешения конфликта используется как правило копипаста, либо хитрые конструкции типа Ext.Window.superclass.initConstructor.apply( this, arguments ) которые как ни странно ещё и работают через жопу.

И ничего во множественном наследовании плохого нет. Бывает плохая декомпозиция, да.

[agagey]

А меня вот эта запись смущает. Вроде, всё правильно, и даже цепочки прототипов есть (prototype.prototype...), но что-то сильно не нравится, не пойму что.

var Animal = function(){
this.prototype = new function(){
this.walk = true;
}
}
var Cat = function(){
this.prototype = new Animal();
}
console.log(new Cat().prototype.prototype.walk); //true

[MuLLtiQ]

Ммм… prototype определяется у функции-конструктора, а не у this

var Animal = function() {};
Animal.prototype.walk = true;

var Cat = function() {};
Cat.prototype = Object.create(Animal.prototype);
Cat.prototype.constructor = Cat;

console.log((new Cat()).walk); // true