Как стать автором
Обновить

Комментарии 11

первая поправка для PSR-2 — понравилось, мне кажется правильно решение.
Я никак не мог побывать на php fw days, потому хотел бы спросить тут SamDark, каким образом DI загрязняет API кода?
Когда DI используется как ConainerAware(пример тому phalcon) — да, я понимаю, это не красиво.
Но когда у нас класс принимает класс через сеттер/конструктор — что в этом плохого, или не красивого? Возможно надо потратить чу-чуть больше времени на написание конфига для этого класса, но это же сократит время на написание «некрасивых», как вы сами выразились тестов.
И на счет слоев вопрос. Вы привели в пример кешер: stackoverflow.com/a/8900283/2252648, никаких слоев)
Его трактовка определения DI «немного» отличается от общепринятой.
Имелось ввиду, что не стоит делать IoC в ущерб чистоте интерфейса, иначе да, будет у вас класс с интерфейсом от НЛО и кучей переключателей. С учетом того, что в последнее время в php появились хорошие средства для мока и стаба, можно такие внедренные зависимости уже не интеграционными тестами делать, а просто обрубать на юнит-тестах через эти тулзы.
Я как раз таскание контейнера и имел ввиду. В простейшем DI через член класса, сеттер или конструктор, естественно, ничего плохого нет и я не знаю, как можно что-то написать его ни разу не использовав.
Кстати, предложение по анонимным классам было отклонено, а по вложенным — пока отозвано.

Уже не удивительно — «слишком сложно» :( А потом удивляются почему для сложных систем выбирают что-то другое.
pronskiy, извините за нетерпение, а когда свежий дайджест будет? :) Или изменилось расписание выхода?
Не изменилось, но по обстоятельствам к сожалению пришлось выпуск отложить до следующих выходных :-(
Очень ждем, спасибо!
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.