PHP-DI - сервис контейнер
Вставка
- Опубліковано 12 тра 2020
- Исходники к уроку тут: webformyself.com/php-di-servi...
В объектно-ориентированном программировании сложно представить скрипт, который работает с использованием всего лишь одного класса, так как, по сути, в этом теряется весь смысл ООП.
Классов может быть сколько угодно, а значит и создаваемых на их основе объектов еще больше. И они должны определенным образом взаимодействовать между собой. Конечно, все зависит от поставленных задач и архитектуры приложения, но так или иначе наиболее часто встречаемый случай - это использование объекта одного класса в методах другого. Как раз об этом мы поговорим в текущем уроке. На практике мы с Вами рассмотрим построение сервис контейнера для реализации механизма внедрения зависимостей.
При этом в рамках одного урока, конечно же, мы с Вами не успеем написать все с абсолютного нуля, поэтому на примере библиотеки PHP DI мы посмотрим, как формируются подобные вещи и возможно она заинтересует Вас для использования в своих проектах.
Хоспадя, наконец-то понятное и достаточно подробное объяснение предмета! + качественные голос и видео + исходники!
Благодарю, парни!
Если бы у вас был курс по свежему Slim4 или Twig, я бы купил.
наконец то понятно , что такое DI , теперь в ларке можно будет использовать это. Спасибо.
I couldn't understand the language but the code was pretty clear and I loved the video, great job!
Неплохое объяснение. не хватает поправок на новичка)) Зачем это все в проекте?
Только можно сказать учусь, пишу своё подобие библиотеки в целях обучения и вот да, действительно столкнулся с такой проблемой внедрения зависимостей, когда один класс, зависит от другого, спасибо за решение. Теперь понятно что это за контейнеры всякие в laravel обсуждают
И да, понятно что можно и без этого обойтись, если сам себе режиссёр, но думаю нужно стремится писать, как обще принято
С самого 2012-го, когда DI в PHP вошел в моду, сталкиваюсь с одним и тем же явлением:
необходимость его применения в проекте сигнализирует о перегруженности в архитектуре.
Если требуется автоматизировать цепочки передачи одного объекта в другой, значит, пора что-то рефакторить.
Ну а когда DI применяют просто потому что "это же круто!", тогда вообще ад. Человекопонятность кода снижается в разы
Самое красивое применение DI встретил за всё это время в Yii2 - там используется как раз "ручное" создание контейнера с помощью конфигурации, где задаются имена классов и аргументы конструктора для каждого сервиса.
DI нужен не для красивого применения. Он нужен как некоторая прослойка между твоим приложением и огромным количеством библиотек/фрейморвков, которые вы используете
24:20 Ручное формирование контейнера
А есть оболочка, чтобы userManager ил Mailer тот же не создавался каждый раз новый?
Неплохо! Но не понятно - зачем это нужно.
Делая сильно зависимым инициализируя объект в другом классе - много труда
и этот способ с контейнерами пока настроишь то сё - опять много труда.
пример как раз показал переусложнение проекта контейнером где вместо new Foo(); нужно писать $foo->get('Foo')
А теперь представь что этот Foo(Mail $m) используется в 1000 классов и появилась необходимость добавить в него логгер Foo(Mail $m, Logger $l). Уверяю что этот день ты проглянешь, а ведь еще надо будет проверить что все места в которые ты внес изменения работаю, а тесты пишутся не всегда и не на все. Так же помогает иметь доступ к глобальным объектам таким как работа с базой и выпилить такую штуку как синглтон.
Чтоб я делал без этого видео :)
Интересный инструмент. Однако считаю, что если его пришлось использовать, что то пошло не так на этапе проектирования.
Здравствуйте. Скажите, планируются ли новые курсы по Laravel или Symfony?
Когда же по ларавел курс??
Все хорошо, вот только не понял зачем везде писать эти "спагетти"(\App\Classes ........) если можно просто вверху страницы написать use \App\Classes ........ . Тогда и код более менее читабельным становится, по крайней мере для новичков. И Второе хоть убейте не понял зачем делать такую сложную архитектуру файлов и папок ??? По моему перебор. Не только код должен быть читаемым, но и архитектура проекта должна быть читаема, если можно так сказать . Тогда и "спагетти" станут короче. А вообще, что бы понять нормально DI , надо самому пару проектов написать своим кодом, без библиотек, потому что можно научиться это делать с помощью библиотеки, но понять как это работает нет.
А почему не symfony/dependency-injection?
Как часто Вы слышаши что используют php-di в проектах?
Здравствуйте!
Можно записать урок и по контейнеру symfony/dependency-injection, поросто мне показлось, что php-di более простое для новичков
по моему мнению, все что требуется эта либа даёт.
@@konstantinp440 Ну вроде бы и да
Но, в Laravel не используется
В симфони не используется
Не знаю как дела обстоят с YII
Симфони контейнер достаточно прост в понимании и изучении, и достаточно мощный чтобы в ходе курса дать по нему дополнительные возможности по конфигурации через xml или yaml
Вот я и спрашивал, есть ли те, кто испльзовал эот контейнер где либо кроме уроков.
А если у меня абстрактный класс?
какой нах абстрактный класс??? Объекты от абстрактного класса просто так создать нельзя! А тут речь о объектах!
@@user-km6ic7ud8r , ты бы мне еще ответил через 5 лет. Ну, во-первых, объекты от абстрактного класса не то что "просто так создать нельзя", а совсем нельзя, ибо это абстракция. Во-вторых, в контейнерах можно делать привязку реализации к интерфейсам, к тому же абстрактному классу, например(поэтому я и скорее всего спросил год назад). Ну и в целом это видео я бы не рекомендовал смотреть новичкам, лучше почитать нормальную литературу по этому поводу или в документациях по фреймворку, в том же Symfony/Laravel.
@@mister-ace ну, во-первых, объекты от абстрактного класса создать можно, с помощью наследования, это просто так как от конкретного класса из абстрактного - нельзя! Поэтому, во-вторых, если параметром выступает абстракция, то аргументом может быть объект, супертипом которого является данная абстракция.