7

Почему singleton плохо, а share из DI контейнеров, которые по сути тоже создают singleton - это хороший паттерн? И В чем отличие?

человек мякоть
  • 301
  • Во-первых, синглтон делает 2 действия: контролирует единство экземпляра и полезные методы (ваш код). По хорошему один класс должен отвечать только за что-то одно. Во-вторых, неявные зависимости. Где-то в середине метода может всплыть Class::getInstance() и не один. Явное всегда лучше неявного. К тому же замена реализаций синглтона в классе требует переписывания кода. В-третьих, код сложно тестировать. – ArchDemon May 19 '19 at 19:27
  • Хороший вопрос, почитаю дискуссию – KAGG Design May 19 '19 at 19:30
  • Я работал в компании, которая использовала кучу инверсии управления, аннотаций и неявно исполняемого кода концы логики которого потом не найдешь, только лишь для того, чтобы реализовать синглтон. Это overengineering и нарушение принципа KISS. И проблемы с тестированием синглтона там никуда не делись. – trollingchar May 20 '19 at 14:44

2 Answers2

2

Хороший вопрос.

На самом деле share из DI контейнеров тоже плохо.

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

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

ArchDemon
  • 2,821
Ипатьев
  • 20,813
  • Спасибо!

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

     – человек мякоть May 20 '19 at 19:34
  • Получается, чтобы мне работать каждый раз с этим объектом, в разных файлах проекта, то нужно будет каждый раз создавать объект вместе с его зависимостями + конфигурация ? Я конечно, могу это все обернуть в какой-нибудь wrapper. Но тогда будут плодиться одинаковые объекты, а мне и одного экземпляра для всего проекта достаточно. Как быть? Синглтон ?

    Я думал DI контейнеры решают такие проблемы, поэтому начал копать в этом направлении.

     – человек мякоть May 20 '19 at 19:35
  • Что делать, если синглтон - антипаттерн, Глобальные переменные - Зло. Но задача требует создать только 1 объект ? (думаю пример, когда требуется только 1 объект не нужен, и все так знаю кучу таких примеров). – человек мякоть May 20 '19 at 19:38
  • Идея тут в том, что когда тебе нужен новый объект бизнес-логики, то ты его создаешь не сам, передавая в качестве зависимости контейнер, из которого ты по потребности извлекаешь нужные сервисы, а новый объект тебе создает контейнер и передает в него потребные сервисы через конструктор. – Ипатьев May 21 '19 at 05:04
-1

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

И.М.Х.О. Синглтон надо уметь применять к месту. Вот и всё.

Ramazan Aliskhanov
  • 348
  • Вы не правы. Синглтон хорош для начинающих разработчиков. Потому что обеспечивает единство экземпляра и лёгкое инстанцирование. А плох он как раз у опытных разработчиков. Потому что обладает рядом существенных недостатков – ArchDemon May 19 '19 at 19:29
  • "На мой взгляд" - имеется ввиду, что я выражаю своё лично мнение. Хорошее оно или плохое - это моё лично мнение. Если синглтон - это плохо, то оно плохо для всех - и для начинающих и для опытных. Везде понатыкать синглтоны (как иногда делают начинающие) - на мой взгляд не очень хорошая идея. Как и любой паттерн его надо уметь применять. – Ramazan Aliskhanov May 20 '19 at 10:44