Тогда лучше назови это DependencyContainer

+

Всмысле. Класс с названием core::ServiceLocator это именно что сервис локатор. В него регистрируются сервиси и из него эти сервисы можно достать.

Что это если не сервис локатор.

м?

Да я же сказал - DI контейнер это, а не сервис локатор

СервисЛокатор это:

Constructor() {
   m_logger = ServiceLocator::getLogger();
   m_imageProvider = ServiceLocator::getImageProvider();
}

Сервис локатору обязательно быть синглтоном и обязательно использоваться из-под конструктора?

В этом заключается этот антипаттерн, да

У тебя - DI контейнер

Синглтоном может и не обязательно, но фишка в том, что у тебя скрываются реальные зависимости в теле конструктора
А при DI контейнере все зависимости у тебя в параметрах конструктора

Constructor() {
   m_logger = ServiceLocator::getLogger();
   m_imageProvider = ServiceLocator::getImageProvider();
}

То есть если здесь объект СервисЛокатора будет передаваться в качестве параметра конструктору - то ничего не изменится с принципиальной точки зрения

Так как СервисЛокатор не будет реальной зависимостью класса
Хотя это явно лучше, чем тот вариант, который я описал

Но всё ещё плохо

Да схерали фишка именно в том, что бы юзнуть из-под конструктора?
Тоесть если я юзаю не из под конструктора, то это DI контейнер, а если в конструкторе, то сервис локатор? Не звучит ли это как бред? Даже само название паттерна говорит о нем, "поисковик сервисов". Что-то я в названии Сервис Локатора не вижу CallMeOnlyFromConstructorServiceLocator.

Антипаттерн он из-за того, что люди привыкли юзать в конструкторе. Так бы паттерном был.

Так двухфакторная инициализация - это тоже антипаттерн)

Объект должен быть готовым после конструирования

Сервис локатор должен делать одну вещь. Быть реестром для сервисов. А то, откуда он испольхуется это дело другоею

Ну да, поменяй тему.

Так ты херню какую-то говоришь