Паттерн EventBus или Шина Событий в Unity
HTML-код
- Опубликовано: 7 май 2024
- Понравилось видео? Поддержи Лавку Разработчика!
www.donationalerts.com/r/game...
boosty.to/gamedevlavka
paypal.me/gamedevlavka
Если в проекте множество зависимостей распространяется на события, от этого порождается плотный комок жестких взаимосвязей, то на помощь, для разрядки обстановки в прямом и переносном смыслах приходит EventBus. Паттерн с нюансами, не всего любят, но все соглашаются, он облегчает жизнь.
Разбираем на простеньком примере в Unity, как всегда! Смотрим, лайки ставим, не стесняемся!
Отсылки:
t.me/gamedevlavka - телеграм канал Лавки Разработчика
t.me/gamedevtavern - ламповый чат
/ discord - дискорд
__________
0:00 Предисловие
1:10 Пишем EventBus
2:30 Пишем того, кто будет триггерить события
3:26 Пишем того, кто будет подписываться на событие
4:25 Пишем пример использования
6:00 Избавляемся от опасности при помощи интерфейса
7:30 Дополнительная информация
- Раз уж тут люди говорят о болячках паттерна, то стоит упомянуть решение - просто создать дополнительный слой абстракции, который отнимет у подсистем работу подписки и возьмёт её на себя. Вуаля, код стал независемее, но труднее для понимания. Какое из зол меньшее, пускай уже каждый решит сам
Все верно!
Полезные видосы у тебя, спасибо за работу. Хотелось бы ещё послушать про визуал в юнити: шейдеры, слои отображения, канвасы, работа с камерой, свет в 2d и 3d, создание UI. Наверняка, у тебя есть чем поделиться в этой области.
Не ожидал, что будет понятно с первого просмотра. Спасибо, очень хорошо объяснил идею)
Спасибо за видео. Надеюсь постепенно начну применять
Геймдев который мы заслужили. Спасибо большое ❤
Ооо, спасибо за еду) будем разбираться. Лайк!
Спасибо за видос, я что-то похожее делал, но систему назвал Hook.
Спасибо
Ооо новое видео
я хоть и учусь еще, но и без комментаторов заметил, что в этом подходе что-то не так, особенно в моменте, когда любой может дать и любой может взять) в любом случае было бы очень здорово, если бы автор уделял хотя бы минуту разбора на то, когда стоит применять, а когда нет(сугубо по опыту и для общих случаев, понятное дело, что все равно это все индивидуально)
Это все хорошо до момента, когда тебе нужно добавить яблоко в инвентарь в UI четко после анимации его собирания, а вот добавить в модель и отправить аналитику сразу по клику) представляю, сколько там будет ивентов на это яблоко, а еще в какой спагетти коллбэк хэлл это все превратится, если добавится, условное диалоговое окно в этом процессе или что-то типа того))
Такое в EventBus в принципе не должно попадать) я имею ввиду мешанину в виде секвенций визуала, там это просто не нужно)
Таким образом можно и тригеры в интерфейс выделить. Но в целом, есть ощущение, что если используется такая шина, то где-то что-то плохо спроектировано.
Любой паттерн хорош или плох применением. В совсем маленьком проетке шина будет лишней, большой она превратит в спагетти, а для чего-нибудь среднего - как раз.
Плюс шины событий в том, что она экономит время разработчика, если тот знает где её применять. В итоге можно не морочить голову сложными связями, а сделать по-простому и всё будет прекрасно работать.
@@ichbinschlange все правильно, любое решение - это трата ресурсов, и тому, кто эти ресурсы выделяет (человеко-часы = деньги) решать, какой вариант будет оптимальным)
@@ichbinschlange
А что можно использовать в том же маленьком проекте для событий? Не подскажете? :с
@@cmep4359, всё строго индивидуально. Если проект учебный и опыта работы с шиной нет - отличный повод его получить, если проект совсем маленький и подразумевактся, что так и останется - просто покинуть всё нужное через конструкторы и вообще голову не забивать. Ещё можно в сторону ServiceLocator посмотреть, в контексте безопасности это тоже самое, но код писать проще, ибо не нужно постоянно лезть в God-object с эвентами.
Вообще разных решений миллион, но они, в основном, избыточный для маленьких проектов.
@@cmep4359
Можно попробовать использовать паттерн медиатор
Чай заваривать не буду. Надеюсь, под макароны с котлетой тоже зайдет.
Объясню как я понял , если у нас есть множество объектов на одном уровне, то есть они не на уровень выше и в следствие этого не должны знать друг о друге то ивентбас служит промежуточной связью между ними , что помогает не переплетать их тем самым руша архитектуру
Делаю что то похожее и есть проблема, в определенный момент не можешь придумать название нового евента на похожие по имени (но разные по функционалу) события в игре 😂 не плохо было бы затолкать в какой нибудь дикшинари эти евенты и по имени их вытаскивать. Получится динамическая шина в которой можно регистрировать евенты и нужные ребята по имени смогут туда подписаться и посматривать изменения, будь то квест на сбор определенных предметов на время или ui очки подсчитывает, или инвентарь смотрит что потратили и тд. И вся красота в том что если евента нет в шине то сущность просто живет и ни чего не делает, потому как не подписалась. Тут и модульность любимая и зависимости отвалятся. И интерфейс с ридонли тоже пригодиться. Но списочек с именами квестов придется где то держать в табличке, что бы через недели две не забыть что нарегистрировал 😂
Да, можно и так! Мы говорим про идею, про паттерн, тонкости - дело наживное) Можно сделать динамическим на словаре, правда тогда и наименования событий надо хранить где-то в статике, чтобы память не потекла ручьем)
Обычно event bus как-то глобально используют, и хочется увидеть реализацию, где можно из любого класса триггернуть и подписаться, без монобехов. В том смысле что bus один и все через него работают, типа zenject event bus. Данный пример интересен, но практически не очень полезен, тема, как мне кажется не раскрыта))), но автору виднее...
Просматривается некоторая параллель с системой сигналов и слотов в Qt.
Только в Qt нет никакой централизации обработки этих сигналов, кто угодно может их испускать и кто угодно ловить (главное прописать кто на что и как должен реагировать). В итоге вся программа может быть насквозь пронизана этими связями, и если проект достаточно большой, в нем становится очень тяжело ориентироваться.
Блин. Не могу обьяснить почему, но есть странно ощущение, что это не самая хорошая практика... Но может это и не так.
Имеем god-object, о котором все знают и от которого все зависят. Т.е. ни о какой изоляции компонентов уже речи не идет. Возможно, имеет смысл создать условно "шину", которая сама будет подписываться на события компонентов-источников и дергать методы компонентов-подписчиков. Тоже спагетти, но хоть сами компоненты не будут зависеть от шины. Здесь хоть и интерфейс, но это всё равно зависимость, которая не всегда нужна.
@@andrey_aka_skif в божественных объектах не плохие сами по себе. Антипаттерн может спокойно быть паттерном, как и паттерн в определённых ситуациях может стать антипаттерном.
Это полухак. То есть вроде и паттерн, но если можно обойтись без него - лучше обойтись без него. Мы оцениваем такие вещи на реальных проектах, нельзя заранее сказать, плохой паттерн или не плохой. Знай, что он есть, как можно применить, и однажды, когда тебе скажут сделать игру за 1.5 дня, ты его вспомнишь, вы вместе всплакнете, и сделаете игру в срок
Так и есть, потом не распутаешь все эти связи между десятками и сотнями триггеров и подписчиков.
@@titanovsky человек размышлял о минусах подхода. Я продолжил мысль. Сам подход шины событий используется часто. В тех же микросервисах. Хоть это и не прямой аналог.
Что за цензура на 6:26?
оО, интересно, интересно! Это не часть монтажа, если что
Ютуб заблюрил плохой код. Такое на ютубе нельзя показывать.
Сорян, бро, но я нихера не понял. Но спасибо в любом случае, попробую разобраться