Суть компонентного фреймворка

Начинаем делать свой удобный HTTP-фреймворк на PHP. От нас не скроется ни один нюанс его работы. Мы исследуем его устройство вдоль и поперёк через написание с нуля каждого компонента.

Сегодня в начале нашего пути дадим определение компонентного HTTP-фреймворка. Рассмотрим место фреймворка и библиотек в потоке управления. Встретим и решим проблему совместимости фреймворков путём использования рекомендаций PSR.

  • 00:00:38 - Для чего это нужно
  • 00:02:10 - Что такое фреймворк
  • 00:03:45 - Использование готового кода
  • 00:04:50 - Организация страниц
  • 00:06:46 - Запускающий код
  • 00:07:48 - Анализ Control Flow
  • 00:09:32 - Отличие фреймворка от библиотеки
  • 00:11:09 - HTTP-фреймворки и другие
  • 00:12:54 - Фреймворк использует библиотеки
  • 00:14:09 - Компоненты и пакетные менеджеры
  • 00:18:42 - Фреймворконезависимые компоненты
  • 00:20:38 - Монолитные и компонентные фреймворки
  • 00:23:17 - Легаси монолитных фреймворков
  • 00:24:02 - Проблема несовместимости фреймворков
  • 00:25:23 - Совместимость через PSR

Заваривайте себе тёплого чая и поехали вместе с нами!

Скрытый контент
Комментарии (16)
Игорь

Дмитрий и Юля, большое спасибо за урок. Всё идеально: объяснение, звук, скорость повествования, картинка, разметка. Похоже, что у вас за эти годы вызрела формула идеальной дистанционной лекции.

Сейчас начинаю переписывать активно растущее легаси приложение для обязательной маркировки. Эта серия уроков будет очень кстати.

Ответить
Руслан

Спасибо!

Ответить
Михаил

А по slim уроки пока не будут выходить?

Ответить
Дмитрий Елисеев

Будут

Ответить
Андрей

Спасибо, очень ждал этот курс!

Ответить
iEXTRA

Отличный контент, из других видео узнал для себя много нового и интересного. Жду следующие видео данного курса. Спасибо за вашу работу

Ответить
slo_nik

Добрый день.

Отлично, жду продолжения.

Ответить
Алексей

Спасибо! ждем следующих эпизодов.

Ответить
Евгений

Спасибо! Все по полочкам.

Ответить
Arunas

Спасибо, liuks!

Ответить
Владимир

Рад что долждался обновленного курса.

Инересно почему в качестве образца выбрали Мецио, а не SLIM ? Ведь именно слим Вы используете в других кастах..

Ответить
Дмитрий Елисеев

Потому что только в версии 4.0 от 2019-ого года Slim избавился от жёстких зависимостей и трейтов.

А в момент записи тех скринкастов в 2017-ом году независимым был только Zend Expressive, который сейчас переименовали в Mezzio.

Ответить
Владимир

Про 2019 год понятно, а вот сейчас то, в 2021 почему Zend, а не Slim?

И кстати, Дмитрий, нет ли у Вас материала на такую холиварную тему: почему трейты - плохо ? Я лично пока не понял, где они могут помешать.

Ответить
Дмитрий Елисеев

Про 2019 год понятно, а вот сейчас то, в 2021 почему Zend, а не Slim?

Для разнообразия.

Ответить
Дмитрий Елисеев

Почему трейты - плохо? Я лично пока не понял, где они могут помешать.

Когда программисты в ООП узнают про наследование, многие им начинают злоупотреблять, делая длинные цепочки, наследуя все подряд классы друг от друга, где обычно класс студента наследуется от класса человека:

  A
  |
  B
 / \
C   D

И как-то в C++ сделали множественное наследование классов. Потом оказалось, что с ним программисты сочиняют из классов ещё более невообразимые шедевры:

A  B C
 \ //\
  D - E
 / \/\/
F  G  H

где собака наследуются от табуретки (так как четыре ноги) и радиатора (так как тоже тёплая).

Получилась жёсткосвязанная система. Чтобы понять, какие методы унаследовались и перекрыли друг друга в классе G нужно просидеть целый день. И мелкое изменение метода в классе B может сломать половину проекта.

В итоге во всех последующих языках вроде Java и PHP от множественного наследования реализации (классов) отказались. Оставили только использование интерфейсов. И вообще единичное наследование посоветовали использовать только в крайних случаях. А остальное делать композицией или агрегацией.

Почему трейты - плохо?

Если рассматривать архитектуру в общем, то:

Плохо - это большие классы со слабосвязанными методами и многими ответственностями, копипаста логики, множественное наследование реализации.

Хорошо - это декомпозиция на узкоспециализированные классы, реализующие интерфейсы как контракты, композиция вместо наследования.

Я лично пока не понял, где они могут помешать.

И вот однажды в PHP от одного джентльмена прилетело предложение сделать трейты, чтобы обойти ограничение единственного наследования. И понеслось...

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

Так что плохо - это не сами трейты, а то, что с их помощью часто делают плохие вещи.

Ответить
Владимир

Прекрасный ответ !!

Ответить
Зарегистрируйтесь или войдите чтобы оставить комментарий

Или войти через:

Google
Yandex
MailRu