Кинжал - намного лучший способ управлять одиночными играми, отчасти потому, что вам не нужно беспокоиться о том, как заменить эти синглтоны во время модульных тестов: ваши синглеты будут впрыскиваться с помощью средств, которые вы можете контролировать и переопределять в модульных тестах (т. е. аргументы конструктора и доступные поля).
Dagger создает новый объект граф с каждым новым контейнером для каждого @Singleton объекта таким образом, мы должны создать компонент на уровне приложений
Если вы хотите одиночек на уровне приложений, вы будет хотите сохранить тот же экземпляр компонента в жизненном цикле вашего приложения, вместо того, чтобы создавать новый с каждым новым «контейнером». Компонент будет содержать и предоставлять синглтоны, поэтому вам не понадобится больше одного графика объектов, активного в вашем приложении. Если какой-либо внешний создатель (например, Android или движок сервлетов) создает объекты самостоятельно за пределами кинжала, это может означать, что вам нужно сохранить компонент Dagger в держателе singleton (возможно, в потоковом открытом статическом поле), как вы сделал для ваших старых синглетов; это должно быть легче понять и поддерживать, поскольку вы можете предоставить столько синглетонов, сколько захотите, с помощью кинжала, и только беспокоиться об одном управляемом извне синглете для самого компонента.
В качестве альтернативы вы можете сохранить свои старые синглтоны точно так же, как и у вас, и написать @Provides методы в модуле, чтобы извлекать эти экземпляры singleton, когда ваши объекты, созданные Dagger, запрашивают их. Это позволит вам создавать новый граф объектов всякий раз, когда бы вы ни захотели, и ваши синглеты будут по-прежнему вести себя как одиночные. Однако я бы предостерег от этого, потому что в этот момент ваши сингллеты будут доступны в вашем приложении двумя разными способами, и только те, которые создаются кинжалом или управляемые кинжалом, будут легко переопределены в тестах; это может быть запутанным и трудным для управления.