Как написать один общий Di container?

Question

[ganjo888]

использую отдельный пакет "symfony/dependency-injection" для внедрения зависимостей использую yaml файл.
Дайте пожалуйста пример как можно реализовать один общий контейнер. Например в laravel можно вот так использовать с любого места app()->make('')

Comments

[Mikhail Osher]

// небольшой ликбез

За что я люблю Symfony, что такие антипаттерны там "тяжело" реализовать.
В самой документации Вам намекают, что так лучше не делать.

"Глобальный контейнер" – это прямое противопоставление замечательного принципа Dependency Inversion Principle (D в SOLID), который помогает писать понятный, расширяемый и переиспользуемый код.

Использование такого контейнера вполне применимо, но требует осознания груза, который привносится проекту.
Осмелюсь предположить, что Вы не полностью понимаете плюсы/минусы этого решения, и видите в нём только простоту и удобство.

// по делу
А что хотите им решить? Вы же можете всем сервисам прописать какие надо зависимости. Если нужно создавать сервисы динамически (предположим, на основе каких-то параметров из базы/итд), то для этого есть factories.

[Сергей Нижний Новгород]

Хороший выбор symfony в качесте платформы

[ganjo888]

Mikhail Osher, я хочу чтобы в моем небольшом приложении был всего один instance , то есть если я в одном instance сконфигурирую а из другого попробую вызвать, то я ничего не получу...

[Flying]

ganjo888 один instance у вас и будет, это не зависит от того где именно вы будете доставать этот instance из контейнера.

Mikhail Osher пытается указать вам на другую проблему в вашем желании: если, условно говоря, вы сделаете так как написано у вас в примере, будете использовать глобальный контейнер, тогда вы окажетесь в ситуации когда работа ваших классов будет зависеть от наличия и определённого состояния этого глобального контейнера. Это приводит к целому ряду проблем которые не сразу очевидны, к примеру:

• Это существенно усложняет, если вообще делает возможным, тестируемость ваших классов т.к. вам нужно будет запускать тестовое приложение с разными контейнерами для каждого теста, а контейнер у вас глобальный
  
• Это делает почти невозможным перенос ваших классов между приложениями т.к. помимо переноса самих классов вам необходимо будет обеспечивать ещё и совместимое состояние контейнера чтобы не получить сложноуловимые ошибки в runtime
  
• Это существенно усложняет поддержку и развитие приложения т.к. вы привязываетесь к идентификаторам в контейнере, ожидая что этому идентификатору соответствует instance строго определённого класса. Но в общем случае это может быть не так, поэтому вам необходимо будет либо постоянно проверять что же вы оттуда достали (что добавляет в код кучу лишних runtime проверок) либо опять подставлять приложение под риск получения ошибок в runtime
  

Вместо этого вам необходимо использовать контейнер для того чтобы хранить в нём корректно сконфигурированные instances которые будут получать все необходимые для них зависимости в момент создания.

[Mikhail Osher]

ganjo888, до сих пор непонятно, какую конкретно проблему пытаетесь решить с помощью глобального контейнера. Приведите какие-нибудбь примеры кода.