PHP ООП: внедрение зависимостей и магия рефлексии
HTML-код
- Опубликовано: 8 сен 2024
- Почему ООП в современных фреймворках такое замудрёное? - Узнаем за 4 шага:
1. простой нетестируемый код
2. идеи внедрения зависимостей
3. пример тестируемости, когда есть di
4. муки ручной передачи зависимостей и идеи php Reflection
Не пропустите новогоднюю акцию - newyear.dmitry...
Блин ну Лаврик крутой конечно, просто педагог от бога, доносить свои мысли умеет
Ага, полностью согласен
к сожалению нет - ни плана, ни подготовки, дз придумывает на ходу и не всегда удачно. Для усвоения информации лучше слушать более скучного преподавателя, но у которого все структурировано и ЗАРАНЕЕ приготовлено дз по конкретным темам.
@@simongreyse4171 нууу батенька, это вам в институт, на сухую потреблять новую информацию
@@_diemydarling вот начал смотреть другого человека и понимаю, что он объясняет тему неверно, и понимаю это, потому что слышал правильное объяснение от Лаврика, потому что Лаврик реально закапывается в тему
@@simongreyse4171 структурированная информация - это документация
Спасибо! Хорошо что есть люди которые легко могут объяснить сложное.
Блин, очень полезно, прям глаза открыл, почему что да как в ларавел) Спасибо большое!
Вы шикарный! Творческих успехов вам! И спасибо!
Спасибо большое, все очень понятно. Не каждый так сможет объяснить.
Кучу мест смотрел и не одну статью читал про DI , но в этом ролике единственное, адекватное описание "Зачем?". Конечно, в итоге сам до этого дошел, но сейчас рад, что подтвердилось моё понимание.
Очень классно чувствую себя, когда смотрю это и понимаю большую часть изложенного. Особенно нравится понимать - ЗАЧЕМ что-то создаётся или убирается. Ранее на другом курсе обучали возможностям языка, но без объяснения ЗАЧЕМ что-то нужно. Здесь с этим совсем иначе, что меня радует
:)
Тоже кайфую, причём это видео в котором я впервые вижу PHP, но главные идеи в программировании не зависят от языка, поэтому все понял. Автор отлично объясняет
Очень круто объясняете 👍
Отличная лекция. Спасибо
Чётко и понятно, спасибо!
очень зачетно рассказал!
Очень крутое объяснение!!! Спасибо👍
Было очень интересно посмотреть, хоть я и СиШарпист)😃👍
отличное видео, спасибо, подпишусь)) по поводу идей - всегда было интересно как реализует та же ларка свой актив рекорд) в целом то понятно, но хотелось бы увидеть разбор по полочкам)
Отличный урок
Все новички полюбят di, когда к ним придёт проект на расширение, но без di, а делать надо =)
Хорошее видео. Немного критики внесу. Есть момент, где говорит, что система не может создать объект Model. Корректнее было сказать не может создать объект интерфейса, ведь слушатель может и забыть, что это было интерфейсом, особенно, когда лекция насыщенная. И второе, сделан очень слабый акцент, просто мимолетом упомянулось, что подобные классы контейнеров подходят только для создания классов, не требующих дополнительной настройки, а в принципе состоящие только из классов, создаваемых по умолчанию. Этот косяк данной технологии весьма существеннен. Далее, в-третьих, внедрение правил для интерфейсов и прочие подкрутки и донастройки для отдельных классов приводят уже к тому, что те самые пять сирочек вместо одной всё таки приходиться писать. И если в случае обычного применения интерфейсов нам не надо задумываться, система сама подставит нужное и не будет ругаться, то с контейнерами нужно будет под каждый класс описывать взаимодействие с интерфейсом, что удлинняет код. Спасибо за видео, было полезно и интересно.
Спасибо)
Спасибо
спасибо за РНР, хотеся больше рнр от хороших педагогов, но сложно найти
Самое странно, что когда обучают подобным темам, всегда упоминают про тестирование, а когда обучают тестированию, то дают примеры уровня:
fun sum (a, b) {return a + b;}
Хоть раз бы показали, как тестируют методы контролера, модели, короче как раз то, что вообще непонятно как тестировать.
Дмитрий вы там про атрибуты напутали.
Атрибуты в пхп это аннотации типов в других языках :)
Спасибо большое!
В командной работе ООП выручает, но чаще мешает, потому что структура классов, как правило, спроектирована кем-то раньше, и обязательно через одно место.
А для самостоятельно выполняемых проектов предпочитаю процедуралку )) Накидал в одну библиотеку универсальных функций, в другую - функции для текущего проекта, и не паришься, что где-то что-то не создаётся и не пробрасывается.
Всё-таки 90% любого сайта - это админка, и там лучше не резать код на десятки файлов - потом замучаешься в кучу собирать.
4:36 структура приложения
Во 2 кейсе, где мы колхозно сами реализовали передачу классов в конструктов без интерфйса, мы можем же написать тесты, просто для классов мокМоделей и тд надо унаследоваться от Моделей и переопределить методы же? Поправьте если я не прав? Просто интересно верно ли предположение
Почему не pspstorm?
Меня бесят скобки по PSR! Всегда ставил в JS стиле. Причина: часто пользуюсь фолдингом. Быстро понять структуру -> фолдинг до нужного уровня или фолдинг all с последующим постепенным разворачиванием.
37 минута. Где причина для чего это все надо. Подтвердите или поправьте меня пожалуйста, если я ошибаюсь. Т.е. когда ты работаешь в команде, ты пишешь часть кода, ты вставляешь свой код в большую программу. И тебе надо проверить, как твой код будет взаимодействовать со всем остальным окружением. Т.е. в первую очередь тебе нужно защитить себя, доказать с помощью тестов, что твой код выполняется согласно требований. Если пишешь код один, каким бы он большим не был, ты его знаешь от и до, ты знаешь все его потоки, что откуда и куда идет, какие там данные. То тебе в принципе тесты не сильно полезные, полезные, но как бы не обязательные. Чтобы привести аналогию. Допустим ты кодишь один, зачем тесты. С чем это можно сравнить. Например если ты соединяешь свой код с каким то левым API, у тебя нет возможности там что-то смотреть, править, у тебя должен быть механизм проверки правильности его работы. И получается при работе в команде у тебя (аналогично) нет времени смотреть в чужой код, и ты (твой код конечно) окружен внешним кодом, который от тебя что-то хочет или ты от него что-то хочешь. И этот код меняется независимо от другого кода, и вот при изменениях твоего кода, или кто-то меняет свой код, он должен прогнать тесты, которые взаимодействуют с твоим кодом, и они покажут все ли продолжает так же работать как и прежде. У меня примерно правильные предположения или я в чем то концептуально заблуждаюсь или про что-то забыл?
"почему новичков это дико бесит ", ну потому что все так объясняют, тема вроде простая, а тот же Симан из нее книжку на 460 стр. накатал и ее пересказ не лучшая идея т.к. главные акценты там скрыты за тоннами слов. Но с другой стороны - пусть сами шишки набьют, не на блюдечке же все приносить.
Дмитрий, вы бы хоть соблюдали PSR-12.. Да понятно, что видео не про это, но новички смотря на вас как на гуру, начинают тоже так писать.
А по топику, действительно, хорошие объяснения и DI (хоть он и так прост до невозможности) и рефлексии.
и я еще не до конца досмотрел, но правильно ли я понимаю, что вся ответственность (например в том же 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?
Спасибо