Comments 14
Большое спасибо за статью! Особенно порадовало упоминание Yii3.
Но не могу удержаться от небольшого замечания, тем более, что этот код уж очень диссонирует с толковостью остальной статьи своей вопиющей бессмысленностью. Да, я про try/catch/echo $e->getMessage(). С большой натяжкой его наличие можно оправдать отключённым при разработке информированием об ошибках. Но в этом случае человеку надо садиться учить самые основы, а не внедрение зависимостей. А если информирование об ошибках включено - как это и должно быть - то этот кусок кода становится полностью бессмысленным, поскольку РНР прекрасно выведет сообщение об ошибке и без каких-либо телодвижений со стороны разработчика.
Плюс опять же непонятно, зачем заведомо ухудшать информативность сообщения об ошибке, вырезая из неё такую информацию, как место возникновения ошибки, трассировка стека и тип исключения. Зачем было городить разные типы исключений на каждый чих, если мы всё равно информацию о типе не используем?
Ну и в довершение надо всегда помнить, что такой блок зачастую переезжает из примеров в прямиком в продакшен, где становится уже попросту вредным, вываливая внутренние ошибки клиенту.
Я понимаю, что PHPStorm, как и другие анализаторы, постоянно дёргает за штаны, "Караул, неотловленное исключение, всё пропало!". Но на мой взгляд, это одна из инспекций, которая приносит гораздо больше вреда, чем пользы - приводя к такому вот подходу, "написать абы что, лишь бы мамка не ругалась". Надо не вестись, а наоборот, укорачивать этой инспекции ручки в настройках, ну или хотя бы аннотациями.
Ещё такой вопрос возник при прочтении. В случае, если у нас есть две разных реализации интерфейса, как контейнер с автоматическим разрешением зависимостей различает, какую именно использовать? Я правильно понимаю, что чистого решения у этой проблемы нет, и мы в итоге всё равно указываем конкретный класс - только не при вызове, а где-то в конфигурации?
Делается через конфиг сервис контейнера.
Условно мы говорим когда встречаешь этот интерфейс то для этого класса прикинь эту реализацию, а для этого вот эту.
Если не ошибаюсь то в ларе конструкция
$container->when(кому требуется)->needs(что требуется)->give(тут уже что прокидываем)
В симфони через аргументы в конфиге.
К сожалению точный код не могу накатать, с телефона читал статью.
Реализовал подобное лет 10 назад, для для проекта на zend 1-2 https://github.com/FreeElephants/php-di Чтобы распутать статические вызовы и сделать код тестируемым.
С тех пор хорошо библиотека хорошо себя показала в проде в проектах на самописах или без больших фреймворков, где нужен простой di.
Symfony с yaml, имхо проигрывает нативным php-конфигам, особенно с сахаром и типизацией последних версий.
До сих пор кажется неправильным тянуть по цепочке сотни или тысячи классов, которые никогда не будут использоваться в рамках обработки текущего запроса. Условно в рамках класса другой класс может быть вызван в крайне редкой ситуации в 1 запросе на миллион, но мы каждый раз будет его тянуть в конструкторе, а не при необходимости на месте. Можно использовать прокси, но тоже какой-то костыль. Ладно бы это было приложение, которое один раз загрузилось, инициализировалось, висит в памяти и обрабатывает запросы.
Ни кто не заставляет использовать инъекции, для всех зависимостей, через конструктор, можно инъектировать только psr контейнер через конструктор, а его уже передавать в фабричные методы. Тем самым мы и динамический контекст сохраним, и при этом сможем подгружать классы по мере их необходимости. Этакий сервис локатор на максималках.
Интересные фантазии нейросети на тему Yii3, но нет, у нас не так на самом деле.
Внедрение зависимостей в PHP: от основ до фреймворков