Канал событий (event channel) ► Шаблон проектирования ► Урок №3
HTML-код
- Опубликовано: 5 сен 2024
- Канал событий (англ. event channel) - фундаментальный шаблон проектирования, благодаря которому мы можем создать гибкую систему уведомлений с подписками, Блэк Джеком и куртизанками!
#шаблоны_проектирования #куртизанки #Канал_событий
*
★ Автор: Дмитрий Афанасьев.
★ Телеграм с новостями: t.me/i640kb
★ Канал: clck.ru/JVYct
*
► Выразить благодарность, поддержать донатом развитие канала.
★ www.tinkoff.ru...
★ www.donational...
*
► Еще интересные курсы:
★ Видеокурс по Laravel: clck.ru/JVYa2
★ Видеокурс по Git: clck.ru/JVYYm
★ Объяснение SOLID: clck.ru/JVYXq
★ Шаблоны проектирования: clck.ru/JVYX7
★ Структурные шаблоны проектирования: clck.ru/TVB9Y
★★★ Все курсы → clck.ru/JVYVd
*
► Обязательно к изучению любому разработчику
★ www.ozon.ru/ca...
★ www.chitai-gor...
⚝⚝⚝ Покровители канала:
► Константин [ ⚝⚝ Меценат ]
Сообщение: "Спасибо за отличные уроки по Laravel";
Сообщение2: "Материал такого уровня можно смело продавать, а вы дарите бесплатно. Не могу пройти мимо и не поддержать ещё раз";
.
► Mordwin
Сообщение: "Спасибо за контент. Устроюсь на нормальную работу - подкину больше)";
.
► Александр Мельник
Сообщение: "Вы снимаете классные уроки, спасибо.";
.
► Дмитрий
Сообщение: "На кусочек провода для нового света :) Огромное спасибо за laravel курс! Помимо всего полезного оч порадовало то, что видео не сухие, есть какие-то отступления, шутки. Но… Я поленился и сам закодил далеко не всё. Хотелось бы получить последние исходники (Laravel, урок №50). Email ****"
.
► Алексей Сукач
Сообщение: "Спасибо за уроки. Надеюсь, не забросишь)"
.
► Lavr
Сообщение: "Большое спасибо за канал!"
.
► Павел Пожетнов
Сообщение: ""
.
► Александр
Сообщение: "С нетерпением жду продолжения!!!";
.
► Алексей Украинцев
Сообщение: "Спасибо за курс жду продолжения, особенно на тему пользовательских ролей";
.
► Александр
Сообщение: "Дмитрий не бросайте начатое! Большое спасибо за то что вы уже сделали! ИМХО отличная подача материала и разъяснения. Буду ждать продолжения.";
.
► Николай Савин
Сообщение: "Спасибо за знания";
.
► Аноним
Сообщение: "Спасибо за курс, особенно нравится материал про архитектуру приложения.";
.
► Yoyshinoda
Сообщение: "Спасибо за видеокурс по Laravel ( уже появилось желание просмотреть другие). Благодаря этому курсу очень легко ощущаю себя в переходе с C++/C# (Пара-тройка лет в коммерческих проектах) на php. Из пожеланий, с удовольствием, бы просмотрел некий ваш личный топ литературы по этому делу";
.
► Аноним
Сообщение: "Для поднятия настроения";
.
► NGL Biathlon
Сообщение: Большое спасибо за курсы!";
.
► Иван
.
► Tetragrammaton
Сообщение: "Дмитрий, спасибо за вашу работу.";
.
► Oleg Yurchenko
Сообщение: "Спасибо! Пили видосы чаще! SeriousSloth";
.
► Аноним
Сообщение: "Хотелось бы чтобы почаще видео были";
.
► Дмитрий Лейко
Сообщение: "Спасибо за уроки!!! Удачи!";
.
► Andrew
Сообщение: "На пиуко) P.S. Спасибо за крутой курс!";
.
► Виталий Котов
Сообщение: "Привет! Спасибо за видео, но к сожалению застрял в самом начале, не могу двигаться дальше, интернет перерыл, но по английски я не очень(что бы читать форумы), а по русски не нашел ничего, а что нашел, то не работает. Ответь пожалуйста на мой вопрос..";
.
► Паша Гудман
Сообщение: "Не так давно наткнулся на ваш канал с целью грамотного подхода к изучению Laravel и, в целом, процесса разработки. Спасибо за то, что вы делаете. Удачи в вашем деле.";
.
► Ярослав;
.
► Дмитрий
Сообщение: "Спасибо за уроки, смотрю параллельно еще курс, такой нудный в отличие от твоего, так держать"
;
.
► Руслан Васильчиков
Сообщение: "Наконец-то я продвинулся дальше миграций в изучении Laravel. ** * как-то не зашел ;)"
;
.
► Александр;
.
► Бахтиёр
;
Спасибо за поддержку, друзья!;
Спасибо.
все довольно понятно но еще бы добавить пару примеров из реальных проектов где такой механизм реально имеет место.
Все очень понятно. Спасибо за видео урок!
Спасибо за видео.Коммент в поддержку!
да это же кафка)))
Сложное, по простому. Как всегда like👍
Thank you SO MUCH!!!
С магазином классная метафора получилась.
Благодарю
8:23 нужно было в примере вместо картофеля использовать персики (если ты понимаешь о чем я)
Любую фразу можно опошлить просто добавив "если ты понимаешь о чем я" 😂😂😂
Спасибо за Твои видео
С первого раза не зашло. Надо пересмотреть. А это значит только одно - Урок супер! Спасибо!
Супер
Спасибо большое за контент !)
Кстати. В примере присутствуют эллементы контейнера свойств, в виде добавления подписчика на определенные новостные темы.
И элементы дилегирования, в виде публикования из класса Паблишер, через класс КаналСобытий
Но паттерн не зашел, нужно будет пересмотреть, правильно сказали - не из легких! Спасибо за видос.
Спасибо за ликбез! :-)
увидел диаграммы хочу дать тебе идею создать пару видео по UML, дабы новички могли читать диаграммы к тем же шаблонам проектирования
про UML - это интересно. Никто не разбирает - все думают, что всё ВСЕМ итак понятно. А жаль...
очень Гуд
Хорошее видео, исчерпывающее, но жаль нет видео по другим упомянутым похожим паттернам.
Везде "издатель-подписчик" приравнивается либо к "event channel", либо к "observer". Где можно узнать, что есть паттерн "издатель-подписчик" и чем он отличается от этих двоих?
У меня сейчас взрыв мозга на событиях
Хотя по большей части он просто запутанный
хорошее видео! было бы супер если бы еще можно было получить исходный код для детального разбора...
Запрос на исходники через донат - см описание к видео (указать имэйл и видео).
держи лайк
Надо было Джону на персики подписываться =)
Привет! Очень тебе благодарён за эти великолепные уроки! Пожалуйста, прикрепляй линк на архив самого кода или доступ на репозиторий. Спасибо!
Благодарю за отзыв! Видео о том как получить исходники - ruclips.net/video/Hz7U5XiPkkg/видео.html
Ведь кто-то найдет это видео по тегу #куртизанки ))
диман., пиши ещё!!!
А Вы батенька хайпожор ))) Винтер из каминг (привет Арие, Сансе и Джону)
Во период создания видео смотрел игру престолов 😉
Интересный пример)) Если кто-то подписался - добавляем его в код?))) 🤣 думаю сабскрайбы должны храниться в базе, и при выпуске новостей от винтерфела делаем простую выборку с базы кто подписан на винтерфел и форичем каждому шлём mail()
Это не верное замечание - недостает правильного (более корректного), по вашему мнению, примера для данного шаблона.
@@DmitryAfanasyev именно! Как по мне, прикольно когда у тебя появилось задание/работка с чем-то новым или интересным, и ты на конкретном боевом примере решаешь задачу, дабы понимать в каких ситуациях какие методы использовать. Вот у меня сейчас средней сложности задача, думаю об архитектуре, что лучше применить, изучаю материалы по этой теме, а все решают задачу вывода хелло ворлда с использованием трейтов, интерфейсов, абстрактных классов и прочих приблуд. Но никто не объясняет в чём разница абстрактного класса и интерфейса, когда лучше их применять и для чего... Такие знания никакой пользы не несут, наоборот еще больше запутывают ищущего ответы... Возможно, Вам стоит брать конкретное задание на фрилансе по теме урока и разбирать в боевых условиях? Заодно показывая как правильно писать код и рефакторить после предыдущих программистов? Это было куда полезнее знания, как по мне.
Ну и как должно выглядеть ТЗ для этого шаблона? Ну чтобы найти его на фрилансе. Что касается различий между интерфейсом и абстрактным классом - 1) это база ООП, но если база оказалась не понятной, то просмотрев данный курс - понимание должно прийти. Тут уже из названий понятны и механики и области ответственностей. Так же вы допустили логическую ошибку - оценили одно видео, сделали выводы и эти выводы распространили на остальные видео. Где получается придумать пример "из реальной жизни" - там они представлены. В этом же курсе подобного много.
@@DmitryAfanasyev 1) я посмотрел весь курс, некоторые видео по второму разу посмотрел. Лично мне - понятна разница между абстрактным классом и интерфейсом. 2) Что касается практики - тут смотря от чего отталкиваться, от темы урока или от задания и какие проблемы можно решить выполнив его. Если всё же отталкиваемся от темы урока - возможно есть смысл найти менеджера (которых всё больше с каждым днём и я активно продвигаю эту идею), что есть смысл переложить организационные вопросы (общение с заказчиком, помощь в составлении ТЗ, обсуждение оплаты и т.д.) на отдельного человека, за 20-25% от суммы заказа. Лично моя практика показала что так вы можете зарабатывать в 2+ раз больше, с меньшим гемороем)) И такой человек-менеджер, при должной мотивации найдёт вам нужное задание. Например - сейчас всё больше заказов на ТГ ботов, и разобрав 1-2 задания на них вы сможете найти классные моменты где можно раскрыть тему очень хорошо!) Например бот продажник: вы торгуете наушниками, колонками и аудиосистемами, например. У вас есть поставщики, есть паблики где работает данный бот, в которых есть те же подписчики, есть товары, есть заказы (с адресами доставки, оплатой и т.д.). Как и с помощью чего реализовывать такую задачу? Какая оптимальная архитектура должна быть? На первый взгляд задание кажется простейшим, но только начинаешь его делать ты понимаешь что не знаешь какие классы/интерфейсы/трейты лучше создать? Ведь нам нужно обрабатывать пришедшие данные с API, нужен коннект к базе, должны быть юзеры, товары, заказы и т.д. Должен быть админ (заказчик) который может управлять всем этим (добавлять товары, смотреть продажи, тенденции и т.д.). Вот вам банальнейший пример задания где можно раскрыть тему и заданий море, уверен при желании взять подобное Вам не составит труда)
Это очень странный подход к созданию обучающего контента.... Полагаю это проигрышный подход.
Вот тут уже забористо)
Дмитрий, очередное большое спасибо за понятное изложение!
Вопрос - почему Подписчику не передается название События?
Если Бурерожденная кроме бананов, подпишется еще и на персики, то как она узнает, о чем именно data?
В других реализациях - этого также нет. Это считается излишним?
Очень интересный паттерн, как я понимаю на нем в основном делают push/email уведомления, но с видео не понял каким образом эти 3 интерфейса связаны между собой. Попытаюсь восзоздать паттерн, может получится разобраться)
Event связывает "поставщика" и "подписчика" работая посредником, как в игре "сломанный телефон", только телефон не сломан)))
"Поставщик" выбирает уникальное имя и привязывается к "событию", а "подписчик" заявляет "событию" об обновлении каких уникальных имен его оповещать. По сути и "поставщик" и "подписчик" в своей реализации просто делегируют исполнение "событию". Как раз прошлый паттерн))) И Поставщик и Подписчик выполняют чисто представительские функции.
latest PHPUnit10 use this pattern intead of prefious huge runtime interfaces
Я тут покопался немного в обсерверах laravel и мне показалось, что в laravel обсерверы устроены именно этим паттерном, где каналом связи указывается Dispatcher. Там нет прямой связи между обсервером и моделью. При регистрации Обсервера к модели методом observe, ларавел ищет все подходящие для событий методы в обсервере и заносит их в Dispatcher и когда нужно тригерить событие, то он делает это через диспатчер, который является каналом событий. Правильно ли я понимаю, что это именно этот паттерн, о котором рассказывает Дмитрий. Если да, то путанница с названиями глубокая получается.
Есть еще поведенческий шаблон проектирования Observer (Наблюдатель) - скорее всего это именно его реализовали в обсерверах Laravel. И да, есть множество шаблонов которые похожи друг на друга и некоторые являются частным случаем других и тп. Это может вызывать путаницу, но в конечном итоге это не важно так как нам главное научиться приёмам ООП, познать всё величие манипуляций с объектами, а не просто тупое наследование.
пишу подобное для движка на ноде. интересно никто не делал. что бы евент мог публиковатся в одновременно в несколько топиков, очень удобно группировать месседж по нескольким топикам, грубо говоря джон подписался на винтерфел и на застену, но если придет новость что из застены в винтерфел придут мертвецы, новость одна, то новость не должна придти два раза на каждый канал, потому что джон тупой, подумает что мертвецы пришли дважды, и опять будет джон ты ничего не знаешь....
Как на счёт методов unsubscribe и что-то вроде deletePublisher, deleteSubscriber?
Не избыточен ли первый, и имеют ли смысл делиты?
почему Laravel? самый нечитабельный Фреймворк. года 3-4 назад вытаскивал от туда soket это кошмар vendor
А какой самый читабельный фреймворк?
@@DmitryAfanasyev я Psr но основа Mezzio 1)laminas-diactoros - все почти используют 2) laminas-servicemanager мне понравился мини фреймворк отличный.
взяли Symfony под шаманили и сделали Laravel для Junior
Погуглил. Laravel все еще И самый популярный И гораздо популярнее вышеперечисленного. Кто такие эти "почти все" - вопрос. Полагаю вы личное мнение выдали за общее даже не обратившись к статистике... Или есть рейтинг фреймворков где ваши первые, а laravel на последнем месте?
Это плохо что лара появилась как улучшенная версия симфони? А знаете как появилось то о чем вы говорите? Видимо нет. Ща расскажу. Жил был Зенд. На второй версии он заболел, а на третьей помер. И из его разлагающегося тела вылезло... Вот то что вы написали... Мне кажется быть надстройкой над симфони лучше....
какой смысл не выкладывать код? сам код важнее чем тонны воды в этом видео
Всмысле куртизанки? xD
Если ты понимаешь о чем я 😏
Всем привет. Сорь что немного не в тему но сегодня у одного человека подсмотрел способ получение обьекта по id.
Например было:
public function edit($id)
{
$item = $this->blogPostRepository->getEdit($id);
if (empty($item)){
abort(404);
}
$categoryList = $this->blogCategoryRepository->getForComboBox();
return view('blog.admin.posts.edit', compact('item','categoryList'));
}
А можно этот же код написать как:
public function edit(BlogPost $post)
{
$item = $post;
//лень было менять переменую во вьюхе с $item на $post
$categoryList = $this->blogCategoryRepository->getForComboBox();
return view('blog.admin.posts.edit', compact('item','categoryList'));
}
Дмитрий хочется узнать ваше мнение по поводу данного способа
Перенеси этот коммент под соответствующее видео - там и отвечу....
Дмитрий делал уроки с репозиториями, показывая грамотную (это поддерживаемую и расширяемую) архитектуру приложения. К его урокам можно было бы добавить сервисы и вообще шик.
Смысл в том, что ларавел предоставляет удобный способ, чтобы быстро и просто наваять сайт (это второй способ), по идее можно даже контроллер не создавать, а сразу все в роутах написать.
Если говорить о грамотном написании и использовании SOLID, то репозиторий представляет прокладку между логикой и базой данных, эту прокладку можно заменить и все будет работать. Пример с тем же Ларавел: вы пишите репозиторий используя Eloquent, проект разрастается и вы решаете написать все на чистой БД . Что гласит солид? То что проект должен быть открытым для расширения и закрыт для изменения. Вы можете создать еще один репозиторий но уже на БД и включить его через Контракты в сервис провайдере ни трогая ничего в текущем проекте. И в любой момент обратно. Д Сможете это сделать без репозитория? Нет.
Херь, конечно, ещё та...
Не спеши с выводами . Возможно с опытом оценишь. Когда шаблон кажется херью, можно просто взять его во внимание.