Обёртки для создания классов: зло или добро?

Их не надо реализовывать. Про это и говорил предыдущий оратор. JS — прототипный язык программирования. Программист-классовик должен изменить свое мышление, а не пытаться сделать кучу оберток и «доточить» JS до классового языка.

А, ну тогда извиняюсь, к вам «претензий» никаких :)
Плюс в карму «за беспокойство» :)

Согласен, это выражение слегка абсурдное. Но оно скорее от путаницы в понятиях.
Я не говорю, что выш посыл лишён смысла, я говорю о том, что, может быть, подход к изложению проблемы стоит переделать, зайти с другой стороны.

Тем что во втором подходе в this будет соваться всё подряд, а в первом — только то, что нужно показать наружу.

Если это Own Property то возвратит true если Property делегируется от прототипа или его нет в цепочке прототипов будет false.
var a = [];
a.hasOwnProperty('push'); // false push in prototype
a.pushh = function () {};
a.hasOwnProperty('pushh'); // true pushh is own property


В инкапсуляции и немного большей аккуратности чтоли в коде.

Функция и объект в одном лице

Язык программирования — для программиста. Необходимость в языке программирования и программировании в целом — это, повторю, борьба со сложностью. Чем более высоко абстрактен язык, тем эта борьба становится легче — путём человек-приближенных, высоко-абстрактных понятий ты описываешь ту или иную систему.

Так вот, если, например, в биологии, для моего удобства, чтобы мне легче было «побороть некую хаотичность» я могу классифицировать объекты — т.е. группировать их по особому набору признаков; разделять их; видеть закономерности (опять же — набор свойств) у одного объекта, и видеть, что они отличаются у другого объекта, то почему бы мне этого не сделать в программировании?

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

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

В некоторых языках (Java, C++, др.) класс напрямую связан с понятием типа. Но в общем же случае, для того, чтобы иметь возможность классифицировать, нужен лишь классификационный тег (classification tag). Иногда называют тегом типизации (type tag) или, опять совсем просто — типом. Это некоторое свойство (или набор свойств в общем случае), которое позволяет однозначно определить объект твоей классификации от объекта с таким же набором свойств.

Как я отметил выше, первая главная операция в ООП — это возможность порождать (construct) объекты. Если мы примем, что объект — это просто «набор свойств и поведений», то синтаксически мы можем прям так эти свойства со значениями и описывать:

var point = {x: 1, y: 2};

Если нам нужно три «точки», то:

var a = {x: 1, y: 2};
var b = {x: 3, y: 4};
var c = {x: 5, y: 6};

Но очевидно, что повторное использование кода (code reuse) методом «copy-paste» — это примитивная методика программирования (что если нам понадобится 100, 1000 точек?). Поэтому нам нужен некий удобный сахар для генерации объектов со схожей структурой. И самый простой способ сделать это — это использовать обычную функцию (да-да, точно так же, как мы всегда делаем, когда код повторяется больше двух раз — так называемое «правило двух» — «если код повторяется больше двух раз, вынеси (инкапсулируй) его в функцию».

function makePoint(x, y) {
  return {
    x: x,
    y: y
  };
}

var a = makePoint(1, 2);
var b = makePoint(3, 4);
var c = makePoint(5, 6);

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

Так вот, основная цель конструктора, как показано выше — это всего лишь удобный код реюз — генерация однотипных объектов.

Но. Чтобы классифицировать твои объекты, недостаточно их просто генерировать. Нужен классифицирующий тег. Т.е. у собаки тоже 4 конечности, но она отличается от человека.

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

makePoint.prototype = {
  constrcutor: makePoint
};

И модифицированный способ создания:

function makePoint(x, y) {
  return {
    __proto__: makePoint.prototype,
    x: x,
    y: y
  };
}

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

a.constructor // a.constructor -> not found, a.__proto__.constructor -> found == makePoint.

Разработав всё это (нашу фабрику «makePoint» по генерации объектов-точек), мы придём к выводу, что некоторые вещи можно оптимизировать, убрать сложность (мы ж со сложностью боремся!):

1. уберём (да, для сахара) этот префикс «make», заменим его ключевым словом «new»;

2. сделаем return опциональным (правда, на кой ляд он нам в общем случае? — пусть система сама знает, что надо вернуть объект);

3. будем создавать вспомогательный объект автоматически за кадром и устанавливать __proto__ тоже «по-тихому» (ты хочешь повторять это ручками каждый раз? — я нет);

4. введём какое-нибудь специальное слово (например, this), чтобы ссылаться на созданный объект и не писать каждый раз эти скобочки { и }. Хотя, тут двояко, иной раз со скобками удобней.

5. что-нибудь ещё придумаем…

В итоге, мы получим систему конструкторов в JS:

function Point() { // no "make"
  this.x = x;
  this.y = y;
}

var a = new Point(1, 2);
var b = new Point(3, 4);
var c = new Point(5, 6);

a.constructor // Point

И это именно процесс генерации и классификации. Вот то, что описано выше — от и до — это есть класс. И в JS, да, он реализован вот в таком виде. Дальше, пожалуйста, добавляй сахар наследования (связывай вспомогательный объект-прототип с другим объектов по тому же механизму делегации) и т.д.

Технические хаки (типа «я щас подменю свойство constructor» и т.д.) — меня, как программиста, вааапще не касаются. Удобно мне так классифицировать объекты — я классифицирую. Не буду я ничего ломать, подменять constructor, использовать поломанный [[Class]] в каком-нибудь движке и т.д.; я буду просто программировать в классифицирующем стиле. Если мне надо.

Если не надо. Пожалуйста — полный арсенал утилит для бесклассового (хаотичного) реюза. Здесь уже никакой классифицирующий тег, естественно, не нужен. Здесь уже наоборот, другой объект, если он крякает, как мой, тоже (по идее!) пройти «тест на утку».

В итоге, в JS (как и в любом другом языке с делегацией) можно программировать как с классами, так и без них. Но в классовой системе нельзя программировать в бесклассовом режиме.

… связка «конструктор + протоип» с классифицирующим стилем программирования.