Security с характером, или еще несколько слов о паттерне Singleton

[DmitryKazakov8]

Может глупый вопрос, но чем отличается от export const dataBase = new DataBase()? При импорте из разных мест придет один и тот же инстанс по правилам ES Imports. И DI соответственно class { private dataBase = dataBase; } без контейнера, передающего значение через декоратор.

[Maxim_from_HW]

Вопрос не глупый, а очень даже интересный. В теории, предложенный вариант будет работать, пока забывчивый разработчик не воткнет private dataBase = new dataBase
Чтобы этого не случилось — и закрывают конструктор.

[DmitryKazakov8]

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

[Maxim_from_HW]

Пример паттерна — схематичный, для описания принципа создания. Увидеть его реализацию можно, если залезть «под капот», например, Apollo или TypeORM. А «снаружи» да, просто подключение через DI.

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

[Alexandroppolus]

И DI соответственно class { private dataBase = dataBase; } без контейнера, передающего значение через декоратор.

Это уже не DI :)
За DI на самом деле стоит SRP, то есть класс не занимается резолвом зависимостей самостоятельно — это не его задача. А синглтон может и перестать быть синглтоном.

[DmitryKazakov8]

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

[Wladgaint]

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

Без объяснения всего вот этого тема не раскрыта.

[Maxim_from_HW]

Просто, чтобы раскрыть этот абзац, надо еще две статьи написать) Если тема интересна — обязательно раскроем.

[DmitryKoterov]

Singleton отличается от глобальной переменной только одним: он «ленивый». Т.е. если никто ни разу не запрашивает обращение к БД, то и соединение не откроется.

Все, больше нет отличий, во всем остальном это — такая же глобальная переменная, с той же самой кучей минусов.

[Maxim_from_HW]

Главная проблема глобальной переменной — ее может переписать кто угодно, не уведомив «остальных потребителей». Синглтон переписать невозможно. Именно поэтому он и используется как хранилище (!) глобальных переменных. Это сейф для тех данных, которые нужны всем, но должны быть защищены от несанкционированной перезаписи.

[DmitryKoterov]

Ничего подобного. Глобальная переменная тоже может быть объявлена как const. Разница только в «ленивости».

[Glebkiselev11]

А почему бы просто в js не импортировать объект, это по сути тот же синглтон, только без ритуалов?

[Maxim_from_HW]

Это вчера обсуждали, в ветке комментов выше)

[Zaphkiel]

Маскирует плохую архитектуру.

Но это проблемы не Синглтона, это проблемы архитектуры. Да и как он её тогда маскирует, если из статьи, на искусственных примерах, призванных подчеркнуть что этот паттерн зло, получается: «используется Синглтон — у тебя плохая архитектура»?

Нарушает принцип единственной ответственности класса.

Здесь абсолютно непонятно почему и ни слова об этом в статье не сказано.

Создает проблемы контроля многопоточности.

Это тоже никак не выводимо из текста статьи.

Вывод — надо уметь пользоваться инструментами и не делать из них карго-культа.