Классы и фабричные функции в JavaScript. Что выбрать?

[Cyber0x346]

Я выбрал классы с примесью prototype.

[alex6636]

Вот потом и разберись в коде. Один выберет классы с примесью, второй без примеси, третий фабрики так далее

[RidgeA]

Вот как выглядит описание TodoModel с использованием ключевого слова class:

Вот — описание того же самого объекта, выполненное средствами фабричной функции

не совсем корректно, т.к. методы, которые объявлены в ES6 классе будут свойствами прототипа

[chelovekkakvse]

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

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

[zede]

Статья с слишком провокационными заявлениями. Тут всеми силами выпячиваются достоинства фабричных методов и принижаются все их недостатки, в то время как классы всячески осуждаются и все их недостатки раздуваются. Самый яркий пример:

Фабричные функции содействуют использованию композиции вместо наследования, что даёт разработчику более высокий уровень гибкости в плане проектирования приложений.

, при том что это абсолютно такой же не менее популярный метод и в случае классов, однако «более гибкий», хоть и ограничивает один из подходов. Пункт про безопасность тоже особо весомым не нахожу, ибо если кому-то действительно сильно надо влезть в контекст замыкания, то он может воспользоваться грязным хаком через Function.prototype.toString(). И самое удивительное неужели человек склоняющий к функциональному программированию высказывается против стрелочной нотации которую повсеместно для этого используют. Статья была бы хороша как сравнение подходов, но в итоге в конце она превратилась в сплошное осуждение классов.

[Cyber0x346]

Классы медленнее инициализируются(у меня получилось, что иногда даже медленнее чем DOM ready с большим количеством нод. возможно я где-то не так реализовал архитектуру, но проявляется во всех браузерах)… Единственный, пожалуй, весомый недостаток.

[jMas]

Все верно подмечено про стрелочные функции, мы теряем название функции в стеке ошибок, что серьезно усложняет понимание в каком месте отвалилось. Их нужно использовать с умом.

[iShatokhin]

Все верно подмечено про стрелочные функции, мы теряем название функции в стеке ошибок, что серьезно усложняет понимание в каком месте отвалилось.

Если присваивать стрелочную функцию переменной, то в стеке отобразится имя этой переменной.

(() => {
     throw new Error('Some error');
})();

// Uncaught Error: Some error
//    at <anonymous>:2:12

const funcName = () => {
    throw new Error('Some error');
};

funcName ();

// Uncaught Error: Some error
//    at funcName (<anonymous>:2:11)

(() => {
     throw new Error('Some unnaned func error');
}).name;
// ""

funcName.name; 
// "funcName"

[justboris]

2018 год на дворе, надо пользоваться асинхронными функциями:

async function doSomething() {
  await new Promise(resolve => setTimeout(resolve));

  throw new Error('test');
}

В них стектрейс сохраняется:

> Error: test
    at doSomething (repl:4:9)
    at <anonymous>

[iShatokhin]

1. Зачем в синхронном коде асинхронные функции?
2. Функция doSomething у вас не стрелочная.

[justboris]

Изначально в статье был наброс на стрелочные функции в setTimeout и других асинхронных коллбеках:

setTimeout(() => {}, 0);

Я показал, как этого избежать, правильно используя фичи языка.

Функция doSomething у вас не стрелочная.

Я придерживаюсь правила: все функции верхнего уровня в модуле — обычные, именованные, вложенные функции — стрелочные.

[iShatokhin]

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

[Aries_ua]

Проблема с потерей контекста высосана из пальца. С появлением стрелочных функций это ушло в небытие. У нас даже у джунов не возникает такой ошибки.

Что касаемо скрытия и иммутабельности, то в чем проблема? Так часто кто-то на проекте делаем манки патч? Не делаются тесты и код ревью? За 10 лет девелопинга не было ни разу такой проблемы. Теоретически может быть… Но на практике — не было.

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

Да, статья, если честно, просто однобока.

[justboris]

На прошлой неделе уже публиковался перевод: Элегантные паттерны современного JavaScript: Ice Factory.

В той статье была хорошо рассказана идея, было интересно. А здесь — сплошные набросы на классический подход.

Вопрос к переводчику: а в чем был смысл переводить вторую статью почти с таким же контентом?

[friday]

Проблема с доступностью свойств абсолютно надумана. Всё равно весь код обычно в модулях/функциях, и получить к нему доступ нельзя. А если разработчик использует глобальные переменные для хранения чего-то хоть сколько-нибудь важного, у него проблемы посерьёзнее, чем доступ к свойствам.

[iShatokhin]

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

Тем временем в TC39 добавили private поля.
github.com/tc39/proposal-class-fields/blob/master/PRIVATE_SYNTAX_FAQ.md

пример использования в Canary c флагом `Experimental JavaScript`

[torbasow]

Например, this теряет контекст во вложенных функциях. Это не только усложняет процесс программирования, подобное поведение ещё и является постоянным источником ошибок.

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