Service locator, DI container, Dependency Injection

[Фанат]

Мне кажется, складно написал

Почему Service Locator это зло и что использовать вместо?

Ответили на вопрос 3 человека. Оцените лучшие ответы! И подпишитесь на вопрос, чтобы узнавать о появлении новых ответов.

qna.habr.com

но наверняка найдется в чем поправить

 

[Вурдалак]

Ждём статью про SQL injections

 

[Фанат]

Про инъекции не буду тебе рассказывать, даже не проси!
А вот про хэширование собираюсь написать, да :Р

 

[fixxxer]

В ларавеле на самом деле вполне себе нормальный DIC, как и в Симфони. Но любой DI всегда одновременно и SL, и в Ларавеле слишком просто и "удобно" использовать его как SL, потому что основная цель ларавела обеспечить минимальный порог вхождения. Но никто не запрещает делать нормально.

В общем, я к тому, что если не разобраться в сути вещей, а пытаться просто делать "как в симфони", получится бессмысленный карго-культ. Причем типичный код на симфони "по мануалу" - это карго-культ и есть, выглядит как ООП, но никакого ООП нет.

 

[Фанат]

В общем, я к тому, что если не разобраться в сути вещей, а пытаться просто делать "как в симфони", получится бессмысленный карго-культ.

Ну я это к тому написал, что в 3.4, по-моему, в контроллерах в принципе запрещалось использовать контейнер. Хочешь зависимостей - прописывай в сервисах.
То есть Симфони тебя по рукам бьёт ,и не даёт использовать контейнер руками, а только как поставщик зависимостей для создания экземпляра контроллера. Этот простой ход очень хорошо мозги прочищает на самом деле. Как мне кажется.

 

[MiksIr]

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

 

[Yoskaldyr]

Причем типичный код на симфони "по мануалу" - это карго-культ и есть, выглядит как ООП, но никакого ООП нет.

Очень точно подмечено! Поставил бы еще несколько лайков если бы была такая возможность ))

 

[grigori]

В Laravel нормальный DI.

Class A { function foo(Psr\Log\LoggerInterface $logger) { /* ... */ }; }

$container->bind(Psr\Log\LoggerInterface::class, Logger::channel('single'));
$container->call([A::class,'foo']]);

На соглашениях )))

 

[Фанат]

Очень точно подмечено!

Вот да. Проблема в том, что слова-то я пишу складно, а вот реализовать в коде пока не очень получается...
Как не начну самовар собирать - всё автомат получается....

 

[fixxxer]

В Laravel нормальный DI.

Class A { function foo(Psr\Log\LoggerInterface $logger) { /* ... */ }; }

$container->bind(Psr\Log\LoggerInterface::class, Logger::channel('single'));
$container->call([A::class,'foo']]);

На соглашениях )))

- Доктор, когда я делаю вот так, у меня тут болит. - А Вы так не делайте.

 

[fixxxer]

Вот да. Проблема в том, что слова-то я пишу складно, а вот реализовать в коде пока не очень получается...
Как не начну самовар собирать - всё автомат получается....

А тут примерно как с изучением иностранного языка - можно сколько угодно заучивать таблички с правилами грамматики (=принципы SOLID etc), но умение говорить (=мыслить объектами) придет только с опытом. Погружение в языковую среду (=опыт работы над проектом с грамотной архитектурой с толковым code review) процесс очень ускорит.

 

[grigori]

>А Вы так не делайте.
Ой да ладно, и как же сделать autowire по Psr\Log\LoggerInterface, если там везде фасады?

 

[fixxxer]

Инжектишь Psr\Log\LoggerInterface и все работает.

Я ларавел давно не трогал, может, успели что-то сломать, но с версиями типа 5.1-5.3 принципиально обходился без фасадов и все было ок. (Ну, кроме миграций, но там пофиг). Проблем там, конечно, масса, но в других местах