Можете ли вы объяснить, почему внедрение контейнера хорошо и плохо, и почему объекты, извлеченные из контейнера, не являются зависимостью от их хост-класса?

Question

Я смотрю на это: https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-11-container-meta.md#4-recommended-usage-container-psr-and-the-service-locator

Q1:

Под "BadExample" это показывает ContainerInterface вводится в __constructor, и это "плохо". Но позже, ContainerInterface вводится в RouterExample и это вдруг "Хорошо". Позже то же самое происходит с ExampleFactory и, вероятно, тоже хорошо.

Можете ли вы объяснить, как делать одно и то же может быть как хорошо, так и плохо?

Q2:

Есть комментарий, говорящий: "Это нормально, маршрутизатор находит соответствующую запись контроллера, контроллер не является зависимостью от маршрутизатора". Я не понимаю, почему это нормально ".

Answer 1

Использование DI-контейнера в рамках вашего приложения для разрешения доменных служб является целью ExampleFactory в статье.

Например, в веб-приложении входящий HTTP-запрос передается фабрике, которая пытается создать экземпляр контроллера. Эта фабрика контроллеров - отличное место, чтобы иметь контейнер DI (действительно, многие контейнеры DI переопределяют эту фабрику по умолчанию). В статье даже говорится:

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

Фабрика контроллеров в нашем веб-приложении не зависит от контроллера, который он пытается создать, а занимается только поиском контроллера, чтобы можно было обработать HTTP-запрос.

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