Суть компонентного фреймворка
Начинаем делать свой удобный HTTP-фреймворк на PHP. От нас не скроется ни один нюанс его работы. Мы исследуем его устройство вдоль и поперёк через написание с нуля каждого компонента.
Сегодня в начале нашего пути дадим определение компонентного HTTP-фреймворка. Рассмотрим место фреймворка и библиотек в потоке управления. Встретим и решим проблему совместимости фреймворков путём использования рекомендаций PSR.
- 00:00:38 - Для чего это нужно
- 00:02:09 - Что такое фреймворк
- 00:03:40 - Использование готового кода
- 00:04:41 - Организация страниц
- 00:06:31 - Запускающий код
- 00:07:30 - Анализ Control Flow
- 00:09:09 - Отличие фреймворка от библиотеки
- 00:10:39 - HTTP-фреймворки и другие
- 00:12:20 - Фреймворк использует библиотеки
- 00:13:31 - Компоненты и пакетные менеджеры
- 00:17:56 - Фреймворконезависимые компоненты
- 00:19:49 - Монолитные и компонентные фреймворки
- 00:22:26 - Легаси монолитных фреймворков
- 00:23:10 - Проблема несовместимости фреймворков
- 00:24:30 - Совместимость через PSR
Заваривайте себе тёплого чая и поехали вместе с нами!
Скрытый контент (код, слайды, ...) для подписчиков. Открыть →
Дмитрий Елисеев
elisdn.ru
Чтобы не пропускать новые эпизоды подпишитесь на наш канал @deworkerpro в Telegram
Дмитрий и Юля, большое спасибо за урок. Всё идеально: объяснение, звук, скорость повествования, картинка, разметка. Похоже, что у вас за эти годы вызрела формула идеальной дистанционной лекции.
Сейчас начинаю переписывать активно растущее легаси приложение для обязательной маркировки. Эта серия уроков будет очень кстати.
Спасибо!
А по slim уроки пока не будут выходить?
Будут
Спасибо, очень ждал этот курс!
Отличный контент, из других видео узнал для себя много нового и интересного. Жду следующие видео данного курса. Спасибо за вашу работу
Добрый день.
Отлично, жду продолжения.
Спасибо! ждем следующих эпизодов.
Спасибо! Все по полочкам.
Спасибо, liuks!
Рад что долждался обновленного курса.
Инересно почему в качестве образца выбрали Мецио, а не SLIM ? Ведь именно слим Вы используете в других кастах..
Потому что только в версии 4.0 от 2019-ого года Slim избавился от жёстких зависимостей и трейтов.
А в момент записи тех скринкастов в 2017-ом году независимым был только Zend Expressive, который сейчас переименовали в Mezzio.
Про 2019 год понятно, а вот сейчас то, в 2021 почему Zend, а не Slim?
И кстати, Дмитрий, нет ли у Вас материала на такую холиварную тему: почему трейты - плохо ? Я лично пока не понял, где они могут помешать.
Для разнообразия.
Когда программисты в ООП узнают про наследование, многие им начинают злоупотреблять, делая длинные цепочки, наследуя все подряд классы друг от друга, где обычно класс студента наследуется от класса человека:
И как-то в C++ сделали множественное наследование классов. Потом оказалось, что с ним программисты сочиняют из классов ещё более невообразимые шедевры:
где собака наследуются от табуретки (так как четыре ноги) и радиатора (так как тоже тёплая).
Получилась жёсткосвязанная система. Чтобы понять, какие методы унаследовались и перекрыли друг друга в классе
Gнужно просидеть целый день. И мелкое изменение метода в классеBможет сломать половину проекта.В итоге во всех последующих языках вроде Java и PHP от множественного наследования реализации (классов) отказались. Оставили только использование интерфейсов. И вообще единичное наследование посоветовали использовать только в крайних случаях. А остальное делать композицией или агрегацией.
Если рассматривать архитектуру в общем, то:
Плохо - это большие классы со слабосвязанными методами и многими ответственностями, копипаста логики, множественное наследование реализации.
Хорошо - это декомпозиция на узкоспециализированные классы, реализующие интерфейсы как контракты, композиция вместо наследования.
И вот однажды в PHP от одного джентльмена прилетело предложение сделать трейты, чтобы обойти ограничение единственного наследования. И понеслось...
В итоге трейтами как раз часто копипастят методы для множественного наследования реализации, по-быстрому собирая ими кучи методов в монструозные классы. Вместо того, чтобы подумать и сделать хорошую декомпозицию без них.
Так что плохо - это не сами трейты, а то, что с их помощью часто делают плохие вещи.
Прекрасный ответ !!
Божественно, надо перевести на англ и вставить в конфлюенс 72м шрифтом, чтоб коллеги даже из европы видели. Благодарю
Nginx (pronounced "engine X" /ˌɛndʒɪnˈɛks/ EN-jin-EKS)
Давайте произносить правильно: ЭнжинЭКС, а НЕ ИнДжинкс
Здравствуйте, хотелось бы уточнить один момент. В этом видео Вы называете (например, Mailer и DB) компонентами, которые вызывает либо наш код, либо сам фреймворк. Далее Вы предлагаете их называть библиотеками. Но уже в разделе "компоненты и пакетные менеджеры", Вы разделяете эти понятия. В общем-то, это я и хотел уточнить. Какую разницу вы подразумеваете между компонентом и библиотекой? А то я не могу понять, это по сути синонимы и Вы так говорите просто для удобства или Вы все-таки подразумеваете, что разница есть в этих терминах.
Или войти через: