Можете ли вы использовать внедрение зависимостей везде, где нужен синглтон?

Question

Это может звучать как глупый вопрос, но можно ли использовать DI везде, где нужен Singleton? Или есть случаи, когда синглтон имеет больше смысла? Мой профессор сказал, что есть несколько, но действительных случаев, когда Синглтон "достаточно хорош", но я как-то не доволен этим: - /.

Answer 1

Синглтон это шаблон.Он часто отображается в контейнерах DI или в виде static APIЯ предполагаю, что вы имеете в виду аромат static.

Объекты, экспонируемые через элементы static, обеспечивают минимальное трение для потребителей;вот почему они так привлекательны.Внедрение зависимостей решает ту же проблему (доступ к объектам) по-другому.При использовании DI время жизни зависимостей является деталью конфигурации, а не внутренним фактом.

Вот еще один мой ответ, который решает эту проблему:

Шаблон внедрения зависимостей и Singleton Design

Answer 2

Одной из тем в DI является время жизни объекта, который будет введен. Примеры времени жизни включают Singleton, а также Transient, HttpContext, ThreadLocal, Custom и т. Д. Итак, при использовании DI вы можете указать объект, который будет иметь время жизни Singleton, может быть классом конфигурации, который заполняется при запуске приложения. Казалось бы, это хороший класс для одного человека.

Шаблон Singleton является мощным, но, как и все шаблоны проектирования, он может принести больше вреда, чем пользы, при неправильном использовании. DI и отказ от Singleton также дают лучшую тестируемость.

ура сейчас,

Andrew

Answer 3

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

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

• Я имею дело с API, который я не могу легко изменить.
• Я пишу код, где API может показаться странным, если мне потребуетсяклиент вводит что-то, о чем он не должен знать.Это верно для некоторых статических служебных библиотек, таких как функции для анализа строк, где у меня есть вспомогательный объект, о котором я не хочу, чтобы мои пользователи знали.Обычно я стараюсь избегать этой ситуации.
• Я пишу экспериментальный код, который собираюсь выбросить.В этом случае я часто использую ярлыки, чтобы что-то работать быстро, с пониманием, что код должен быть удален или подвергнут рефакторингу позже.

Если вы еще не использовали их, вы можете захотетьпроверить рамки внедрения зависимостей.Я был очень счастлив, используя Google Guice в коде Java.