Просмотр поста #107648: Разбор ООП с Delphinum

Говоря немного отвлеченно, в mobiCMS я давно экспериментировал с DI и применял это на практике к конкретным задачам.
Если глянете сюды: https://github.com/zendframewo ... e.php
И сюды: https://github.com/Gazenwagen/ ... r.php
тут применяется классический DI с анализом классов, автоматикой и автоподстановкой всех зависимостей.

Да. с одной стороны все хорошо и круто: запросил у контейнера класс - бац, получи его, со всеми зависимостями и т.п.
Но не все так просто: автозависимости накладывают очень жосские требования по программированию. Кажущуяся простота в итоге оказывается реальным гемороем: в DI чересчур много магии и неоднозначностей, зачастую очень трудно проследить ОТКУДА и как берется конкретный объект. Что в свою очередь вызывает геморой с отладкой и поиском багов.

А тогда вернемся к вопросу: на..я DI?
Чтоб облегчить работу?
Ну и где там облегчение, если реальный геморой?

Посему, начиная с 2015 года, большинство серьезных разработчиков фреймворков начали отходить от магии в DI и склоняться к реализации Service Locator в виде Factory-Driven Dependency Injection Container
После, как на практике я "прощупал" данный подход, сам стал его преверженцем: несмотря на необходимость писать множество фабрик, на самом деле поведение полностью предсказуемо, все кликабельно, легко рефакторится и более того. в фабрике можно реализовать любое поведение. что никак невозможно реализовать в автоматических вариантах DI,

Примеры Factory-Driven Dependency Injection Container:
zend-servicemanager (container-interop совместимый начиная с 3-й версии)
Aura.Di (container-interop совместимый начиная с 3-й версии)
Pimple