Да, про невозможность реализовать ваш пример на PHP — был не прав. Через Reflection API такое возможно.
Все же я считаю что это только еще один способ реализации DI, и не стал бы их делить на полноценные и неполноценные :)
Просто в данном случае необходимые зависимости конфигурируются в самом классе. Удобнее.
Речь идет о PHP, и у данного языка нет возможности реализовать приведенный вами пример. Service Locator — один из способов реализации DI.
Согласен, в моем последнем примере $cointainer сам себе играет в роли Service Locator. Конфигурируемые же им объекты получают зависимости либо через конструктор, либо через специально отведенный для этого метод при создании, и в остальном коде нам нет необходимости обращаться к Pimple как с Service Locator.
Как раз таки нет. Возьмем DiC Symfony — мы так же в конфигурации сервиса указываем каким аргументом что подавать.
Для того что бы использовать Pimple полноценно как DiC, а не как Service Locator, просто необходимо и контроллеры приложения обернуть как сервис — появится возможность передавать как аргументы другие сервисы, или назначать их через setter-ы.
Почему не в static или обычном свойстве хранить список ресурсов?
Все же я считаю что это только еще один способ реализации DI, и не стал бы их делить на полноценные и неполноценные :)
Просто в данном случае необходимые зависимости конфигурируются в самом классе. Удобнее.
Согласен, в моем последнем примере $cointainer сам себе играет в роли Service Locator. Конфигурируемые же им объекты получают зависимости либо через конструктор, либо через специально отведенный для этого метод при создании, и в остальном коде нам нет необходимости обращаться к Pimple как с Service Locator.
Для того что бы использовать Pimple полноценно как DiC, а не как Service Locator, просто необходимо и контроллеры приложения обернуть как сервис — появится возможность передавать как аргументы другие сервисы, или назначать их через setter-ы.
В том же примере:
сервис session_storage передается в виде аргумента в конструктор класса Session.