PHP ООП: внедрение зависимостей и магия рефлексии

Почему ООП в современных фреймворках такое замудрёное? - Узнаем за 4 шага:
1. простой нетестируемый код
2. идеи внедрения зависимостей
3. пример тестируемости, когда есть di
4. муки ручной передачи зависимостей и идеи php Reflection
Не пропустите новогоднюю акцию - newyear.dmitrylavrik.ru/

[@eb6006]

Вы шикарный! Творческих успехов вам! И спасибо!

[@_diemydarling]

Блин ну Лаврик крутой конечно, просто педагог от бога, доносить свои мысли умеет

[@intellegon]

Ага, полностью согласен

[@sergeygreyse4171]

к сожалению нет - ни плана, ни подготовки, дз придумывает на ходу и не всегда удачно. Для усвоения информации лучше слушать более скучного преподавателя, но у которого все структурировано и ЗАРАНЕЕ приготовлено дз по конкретным темам.

[@_diemydarling]

@@sergeygreyse4171 нууу батенька, это вам в институт, на сухую потреблять новую информацию

[@sergeygreyse4171]

@@_diemydarling вот начал смотреть другого человека и понимаю, что он объясняет тему неверно, и понимаю это, потому что слышал правильное объяснение от Лаврика, потому что Лаврик реально закапывается в тему

[@rar24]

@@sergeygreyse4171 структурированная информация - это документация

[@psMOV]

Спасибо! Хорошо что есть люди которые легко могут объяснить сложное.

[@armiol]

Кучу мест смотрел и не одну статью читал про DI , но в этом ролике единственное, адекватное описание "Зачем?". Конечно, в итоге сам до этого дошел, но сейчас рад, что подтвердилось моё понимание.

[@user-bb1ew9ky7d]

Блин, очень полезно, прям глаза открыл, почему что да как в ларавел) Спасибо большое!

[@phpuser3243]

Спасибо большое, все очень понятно. Не каждый так сможет объяснить.

[@RomanLyashevich]

Очень классно чувствую себя, когда смотрю это и понимаю большую часть изложенного. Особенно нравится понимать - ЗАЧЕМ что-то создаётся или убирается. Ранее на другом курсе обучали возможностям языка, но без объяснения ЗАЧЕМ что-то нужно. Здесь с этим совсем иначе, что меня радует :)

[@7Denial7]

Тоже кайфую, причём это видео в котором я впервые вижу PHP, но главные идеи в программировании не зависят от языка, поэтому все понял. Автор отлично объясняет

[@user-np9jl4zg3o]

Отличная лекция. Спасибо

[@Alex-De-Berinni]

Очень круто объясняете 👍

[@user-ke4uc3mg8g]

Очень крутое объяснение!!! Спасибо👍

[@anti-bilan]

Все новички полюбят di, когда к ним придёт проект на расширение, но без di, а делать надо =)

[@pilyugin]

отличное видео, спасибо, подпишусь)) по поводу идей - всегда было интересно как реализует та же ларка свой актив рекорд) в целом то понятно, но хотелось бы увидеть разбор по полочкам)

[@user-ow5jh1tt5x]

Чётко и понятно, спасибо!

[@loadmore]

очень зачетно рассказал!

[@user-ly7zn9fr6i]

Отличный урок

[@sergopro4934]

Было очень интересно посмотреть, хоть я и СиШарпист)😃👍

[@saimonsaimon3161]

Спасибо)

[@cranebird1467]

Спасибо

[@EdwardNorthwind]

Самое странно, что когда обучают подобным темам, всегда упоминают про тестирование, а когда обучают тестированию, то дают примеры уровня: fun sum (a, b) {return a + b;} Хоть раз бы показали, как тестируют методы контролера, модели, короче как раз то, что вообще непонятно как тестировать.

[@_diemydarling]

спасибо за РНР, хотеся больше рнр от хороших педагогов, но сложно найти

[@Technical_Expert]

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

[@kookaburru]

Дмитрий вы там про атрибуты напутали. Атрибуты в пхп это аннотации типов в других языках :)

[@user-hp3ip8zh5k]

Во 2 кейсе, где мы колхозно сами реализовали передачу классов в конструктов без интерфйса, мы можем же написать тесты, просто для классов мокМоделей и тд надо унаследоваться от Моделей и переопределить методы же? Поправьте если я не прав? Просто интересно верно ли предположение

[@xoxot_shamana]

Почему не pspstorm?

[@webmaster3984]

4:36 структура приложения

[@andreyrudin2286]

37 минута. Где причина для чего это все надо. Подтвердите или поправьте меня пожалуйста, если я ошибаюсь. Т.е. когда ты работаешь в команде, ты пишешь часть кода, ты вставляешь свой код в большую программу. И тебе надо проверить, как твой код будет взаимодействовать со всем остальным окружением. Т.е. в первую очередь тебе нужно защитить себя, доказать с помощью тестов, что твой код выполняется согласно требований. Если пишешь код один, каким бы он большим не был, ты его знаешь от и до, ты знаешь все его потоки, что откуда и куда идет, какие там данные. То тебе в принципе тесты не сильно полезные, полезные, но как бы не обязательные. Чтобы привести аналогию. Допустим ты кодишь один, зачем тесты. С чем это можно сравнить. Например если ты соединяешь свой код с каким то левым API, у тебя нет возможности там что-то смотреть, править, у тебя должен быть механизм проверки правильности его работы. И получается при работе в команде у тебя (аналогично) нет времени смотреть в чужой код, и ты (твой код конечно) окружен внешним кодом, который от тебя что-то хочет или ты от него что-то хочешь. И этот код меняется независимо от другого кода, и вот при изменениях твоего кода, или кто-то меняет свой код, он должен прогнать тесты, которые взаимодействуют с твоим кодом, и они покажут все ли продолжает так же работать как и прежде. У меня примерно правильные предположения или я в чем то концептуально заблуждаюсь или про что-то забыл?

[@andreyrudin2286]

и я еще не до конца досмотрел, но правильно ли я понимаю, что вся ответственность (например в том же Laravel) на создание объектов и передачу их в контроллеры теперь должна лечь на роутер?

[@andreyrudin2286]

@@noobnoob3037 ок, то чем занимается роутер внутри нам безразлично, но мы говорим роутеру, если придет вот такой то запрос, запусти такой то контроллер и у него такой то метод. Что значит за создание объекта контроллера уже di отвечает не совсем понятно. ок, допустим Вы имеете в виду под DI - dependency injection. кто-то, что-то, куда-то должен внедрить. Ок, с тем что мы должны внедрить мы разобрались, роутер нам возвращает контроллер. Осталось понять кто должен внедрять контроллер и куда он его должен внедрить? ок, шутки шутками. давайте разберем на примере: Laravel роутер, мы определяем маршрут, говорим роутеру какой метод какого контроллера должен запуститься. Route::get('/user', [UserController::class, 'index']); пользователь идет на адрес /user отрабатывает наш UserController->index() я сейчас про что говорю. вот допустим наш контроллер должен работать с каким то репозиторием. по логике которая в видео, что надо в контроллер передавать репозиторий, чтобы его можно было тестировать, это кто-то где то должен делать. Поэтому я и спрашиваю, где это надо делать? понятно что на обычном файле index.php или user.php мы начали отсюда и создаем контроллер и что там надо, и надо ли в этом случае вообще этот контроллер создавать... т.е. в случае с Laravel надо делать примерно так получается? Route::get('/greeting', function () { $repository = new Repository(); $controller = new Controller($repository); $controller->run(); }); типа такого?

[@kandreyk9159]

@@andreyrudin2286 я не php но принципы должны бы те же, создание и lifestyle объектов лежит только на DI, передавать в компоненты он может через конструктор или атрибуты, если объект нужно получить динамически, от типа запроса, например, то DI дает фабрику, а тот же роутер должен объявить такую фабрику как зависимость. Главное что надо уяснить - любой компонент только объявляет зависимости и никогда ничего не создает сам

[@andreyrudin2286]

@@kandreyk9159 досмотрел ролик почти до конца более менее понял о чем Вы с noob говорите. просто это не DI отвечает за создание объектов, а какой то провайдер, которому мы дали контроллер, и он смотрит что ему надо и создает соответствующий объект. Блин, интересная концепция конечно, к изучению Laravel только приступаю, поэтому пока с этим не был знаком, спасибо.

[@xoxot_shamana]

Меня бесят скобки по PSR! Всегда ставил в JS стиле. Причина: часто пользуюсь фолдингом. Быстро понять структуру -> фолдинг до нужного уровня или фолдинг all с последующим постепенным разворачиванием.

[@kandreyk9159]

"почему новичков это дико бесит ", ну потому что все так объясняют, тема вроде простая, а тот же Симан из нее книжку на 460 стр. накатал и ее пересказ не лучшая идея т.к. главные акценты там скрыты за тоннами слов. Но с другой стороны - пусть сами шишки набьют, не на блюдечке же все приносить.

[@ivanivanov2164]

Спасибо большое! В командной работе ООП выручает, но чаще мешает, потому что структура классов, как правило, спроектирована кем-то раньше, и обязательно через одно место. А для самостоятельно выполняемых проектов предпочитаю процедуралку )) Накидал в одну библиотеку универсальных функций, в другую - функции для текущего проекта, и не паришься, что где-то что-то не создаётся и не пробрасывается. Всё-таки 90% любого сайта - это админка, и там лучше не резать код на десятки файлов - потом замучаешься в кучу собирать.

[@phpstudy8625]

Дмитрий, Ваш портрет у меня на стене , спасибо огромное очень грамотно все объясняете !!! Можете на каком-нибудь вебинаре раскрыть тему как правильно написать категории и подкатегории (мин 3 уровня) для магазина на ООП нигде нет толкового материала !!!

[@donpedro8420]

А в чем у вас прблема? Почитайте про хранение древовидных данных в БД. Начните с Adjacency List, если сами будете реализовывать то по проще будет, потом почитайте про nested sets

[@phpstudy8625]

@@donpedro8420 спасибо за отклик и указание правильного направления

[@VladimirKrygin-j4d]

Дмитрий, вы бы хоть соблюдали PSR-12.. Да понятно, что видео не про это, но новички смотря на вас как на гуру, начинают тоже так писать. А по топику, действительно, хорошие объяснения и DI (хоть он и так прост до невозможности) и рефлексии.

[@myroslavshymon7063]

Php в 2021?)

[@viciouswhitkid]

Ого, шутки из 2007.

[@xoxot_shamana]

Пишу из 2023. Php версии 8.3 по производительности совершает насильственные действия сексуального характера над твои любимым (предположение) петухоном.

[@a.osethkin55]

Спасибо