PHP ООП: внедрение зависимостей и магия рефлексии
Вставка
- Опубліковано 22 сер 2024
- Почему ООП в современных фреймворках такое замудрёное? - Узнаем за 4 шага:
1. простой нетестируемый код
2. идеи внедрения зависимостей
3. пример тестируемости, когда есть di
4. муки ручной передачи зависимостей и идеи php Reflection
Не пропустите новогоднюю акцию - newyear.dmitry...
![Дон ДОН, Алаудинов и СБЕЖАВШИЕ из под Курска ахматовцы 😁 [Пародия]](http://i.ytimg.com/vi/dEfCf5IK26Q/mqdefault.jpg)
Блин ну Лаврик крутой конечно, просто педагог от бога, доносить свои мысли умеет
Ага, полностью согласен
к сожалению нет - ни плана, ни подготовки, дз придумывает на ходу и не всегда удачно. Для усвоения информации лучше слушать более скучного преподавателя, но у которого все структурировано и ЗАРАНЕЕ приготовлено дз по конкретным темам.
@@simongreyse4171 нууу батенька, это вам в институт, на сухую потреблять новую информацию
@@_diemydarling вот начал смотреть другого человека и понимаю, что он объясняет тему неверно, и понимаю это, потому что слышал правильное объяснение от Лаврика, потому что Лаврик реально закапывается в тему
@@simongreyse4171 структурированная информация - это документация
Спасибо! Хорошо что есть люди которые легко могут объяснить сложное.
Блин, очень полезно, прям глаза открыл, почему что да как в ларавел) Спасибо большое!
Вы шикарный! Творческих успехов вам! И спасибо!
Спасибо большое, все очень понятно. Не каждый так сможет объяснить.
Очень классно чувствую себя, когда смотрю это и понимаю большую часть изложенного. Особенно нравится понимать - ЗАЧЕМ что-то создаётся или убирается. Ранее на другом курсе обучали возможностям языка, но без объяснения ЗАЧЕМ что-то нужно. Здесь с этим совсем иначе, что меня радует
:)
Тоже кайфую, причём это видео в котором я впервые вижу PHP, но главные идеи в программировании не зависят от языка, поэтому все понял. Автор отлично объясняет
Кучу мест смотрел и не одну статью читал про DI , но в этом ролике единственное, адекватное описание "Зачем?". Конечно, в итоге сам до этого дошел, но сейчас рад, что подтвердилось моё понимание.
Очень круто объясняете 👍
Отличная лекция. Спасибо
Чётко и понятно, спасибо!
Очень крутое объяснение!!! Спасибо👍
Спасибо
очень зачетно рассказал!
отличное видео, спасибо, подпишусь)) по поводу идей - всегда было интересно как реализует та же ларка свой актив рекорд) в целом то понятно, но хотелось бы увидеть разбор по полочкам)
Было очень интересно посмотреть, хоть я и СиШарпист)😃👍
Отличный урок
спасибо за РНР, хотеся больше рнр от хороших педагогов, но сложно найти
Хорошее видео. Немного критики внесу. Есть момент, где говорит, что система не может создать объект Model. Корректнее было сказать не может создать объект интерфейса, ведь слушатель может и забыть, что это было интерфейсом, особенно, когда лекция насыщенная. И второе, сделан очень слабый акцент, просто мимолетом упомянулось, что подобные классы контейнеров подходят только для создания классов, не требующих дополнительной настройки, а в принципе состоящие только из классов, создаваемых по умолчанию. Этот косяк данной технологии весьма существеннен. Далее, в-третьих, внедрение правил для интерфейсов и прочие подкрутки и донастройки для отдельных классов приводят уже к тому, что те самые пять сирочек вместо одной всё таки приходиться писать. И если в случае обычного применения интерфейсов нам не надо задумываться, система сама подставит нужное и не будет ругаться, то с контейнерами нужно будет под каждый класс описывать взаимодействие с интерфейсом, что удлинняет код. Спасибо за видео, было полезно и интересно.
Все новички полюбят di, когда к ним придёт проект на расширение, но без di, а делать надо =)
Спасибо)
Спасибо большое!
В командной работе ООП выручает, но чаще мешает, потому что структура классов, как правило, спроектирована кем-то раньше, и обязательно через одно место.
А для самостоятельно выполняемых проектов предпочитаю процедуралку )) Накидал в одну библиотеку универсальных функций, в другую - функции для текущего проекта, и не паришься, что где-то что-то не создаётся и не пробрасывается.
Всё-таки 90% любого сайта - это админка, и там лучше не резать код на десятки файлов - потом замучаешься в кучу собирать.
Самое странно, что когда обучают подобным темам, всегда упоминают про тестирование, а когда обучают тестированию, то дают примеры уровня:
fun sum (a, b) {return a + b;}
Хоть раз бы показали, как тестируют методы контролера, модели, короче как раз то, что вообще непонятно как тестировать.
Дмитрий вы там про атрибуты напутали.
Атрибуты в пхп это аннотации типов в других языках :)
4:36 структура приложения
Во 2 кейсе, где мы колхозно сами реализовали передачу классов в конструктов без интерфйса, мы можем же написать тесты, просто для классов мокМоделей и тд надо унаследоваться от Моделей и переопределить методы же? Поправьте если я не прав? Просто интересно верно ли предположение
Меня бесят скобки по PSR! Всегда ставил в JS стиле. Причина: часто пользуюсь фолдингом. Быстро понять структуру -> фолдинг до нужного уровня или фолдинг all с последующим постепенным разворачиванием.
Почему не pspstorm?
Дмитрий, вы бы хоть соблюдали PSR-12.. Да понятно, что видео не про это, но новички смотря на вас как на гуру, начинают тоже так писать.
А по топику, действительно, хорошие объяснения и DI (хоть он и так прост до невозможности) и рефлексии.
37 минута. Где причина для чего это все надо. Подтвердите или поправьте меня пожалуйста, если я ошибаюсь. Т.е. когда ты работаешь в команде, ты пишешь часть кода, ты вставляешь свой код в большую программу. И тебе надо проверить, как твой код будет взаимодействовать со всем остальным окружением. Т.е. в первую очередь тебе нужно защитить себя, доказать с помощью тестов, что твой код выполняется согласно требований. Если пишешь код один, каким бы он большим не был, ты его знаешь от и до, ты знаешь все его потоки, что откуда и куда идет, какие там данные. То тебе в принципе тесты не сильно полезные, полезные, но как бы не обязательные. Чтобы привести аналогию. Допустим ты кодишь один, зачем тесты. С чем это можно сравнить. Например если ты соединяешь свой код с каким то левым API, у тебя нет возможности там что-то смотреть, править, у тебя должен быть механизм проверки правильности его работы. И получается при работе в команде у тебя (аналогично) нет времени смотреть в чужой код, и ты (твой код конечно) окружен внешним кодом, который от тебя что-то хочет или ты от него что-то хочешь. И этот код меняется независимо от другого кода, и вот при изменениях твоего кода, или кто-то меняет свой код, он должен прогнать тесты, которые взаимодействуют с твоим кодом, и они покажут все ли продолжает так же работать как и прежде. У меня примерно правильные предположения или я в чем то концептуально заблуждаюсь или про что-то забыл?
"почему новичков это дико бесит ", ну потому что все так объясняют, тема вроде простая, а тот же Симан из нее книжку на 460 стр. накатал и ее пересказ не лучшая идея т.к. главные акценты там скрыты за тоннами слов. Но с другой стороны - пусть сами шишки набьют, не на блюдечке же все приносить.
и я еще не до конца досмотрел, но правильно ли я понимаю, что вся ответственность (например в том же Laravel) на создание объектов и передачу их в контроллеры теперь должна лечь на роутер?
@@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();
});
типа такого?
@@rudinandrey я не php но принципы должны бы те же, создание и lifestyle объектов лежит только на DI, передавать в компоненты он может через конструктор или атрибуты, если объект нужно получить динамически, от типа запроса, например, то DI дает фабрику, а тот же роутер должен объявить такую фабрику как зависимость. Главное что надо уяснить - любой компонент только объявляет зависимости и никогда ничего не создает сам
@@kandreyk9159 досмотрел ролик почти до конца более менее понял о чем Вы с noob говорите. просто это не DI отвечает за создание объектов, а какой то провайдер, которому мы дали контроллер, и он смотрит что ему надо и создает соответствующий объект. Блин, интересная концепция конечно, к изучению Laravel только приступаю, поэтому пока с этим не был знаком, спасибо.
Дмитрий, Ваш портрет у меня на стене , спасибо огромное очень грамотно все объясняете !!! Можете на каком-нибудь вебинаре раскрыть тему как правильно написать категории и подкатегории (мин 3 уровня) для магазина на ООП нигде нет толкового материала !!!
А в чем у вас прблема? Почитайте про хранение древовидных данных в БД. Начните с Adjacency List, если сами будете реализовывать то по проще будет, потом почитайте про nested sets
@@donpedro8420 спасибо за отклик и указание правильного направления
Php в 2021?)
Ого, шутки из 2007.
Пишу из 2023. Php версии 8.3 по производительности совершает насильственные действия сексуального характера над твои любимым (предположение) петухоном.
пишу из 2024, ну как уже выучил html и css?
Спасибо