Синглтоны, как известно, плохая практика, угловые основаны на синглетонах. Это плохо?

Синглтон по-прежнему представляет собой супер полезный шаблон, с недостатками, указанными в этой теме:

Что так плохо о одиночных играх?

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

Они нарушают принцип единой ответственности: в силу того, что они контролируют собственное творение и жизненный цикл.

Они по своей сути приводят к тому, что код тесно связан. Это во многих случаях затрудняет их проверку.

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

Основная часть критики, по-видимому, указывает на очень старомодную реализацию одноэлементного шаблона, где они создаются во всем мире:

public class ClassicSingleton {
   private static ClassicSingleton instance = null;
   protected ClassicSingleton() {
      // Exists only to defeat instantiation.
   }
   public static ClassicSingleton getInstance() {
      if(instance == null) {
         instance = new ClassicSingleton();
      }
      return instance;
   }
}

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

Короче говоря, использование контейнера DI позволяет легко использовать синглтоны без потенциальных плохих эффектов.