Полезные видосы у тебя, спасибо за работу. Хотелось бы ещё послушать про визуал в юнити: шейдеры, слои отображения, канвасы, работа с камерой, свет в 2d и 3d, создание UI. Наверняка, у тебя есть чем поделиться в этой области.
- Раз уж тут люди говорят о болячках паттерна, то стоит упомянуть решение - просто создать дополнительный слой абстракции, который отнимет у подсистем работу подписки и возьмёт её на себя. Вуаля, код стал независемее, но труднее для понимания. Какое из зол меньшее, пускай уже каждый решит сам
Таким образом можно и тригеры в интерфейс выделить. Но в целом, есть ощущение, что если используется такая шина, то где-то что-то плохо спроектировано.
Любой паттерн хорош или плох применением. В совсем маленьком проетке шина будет лишней, большой она превратит в спагетти, а для чего-нибудь среднего - как раз. Плюс шины событий в том, что она экономит время разработчика, если тот знает где её применять. В итоге можно не морочить голову сложными связями, а сделать по-простому и всё будет прекрасно работать.
@@ichbinschlange все правильно, любое решение - это трата ресурсов, и тому, кто эти ресурсы выделяет (человеко-часы = деньги) решать, какой вариант будет оптимальным)
@@cmep4359, всё строго индивидуально. Если проект учебный и опыта работы с шиной нет - отличный повод его получить, если проект совсем маленький и подразумевактся, что так и останется - просто покинуть всё нужное через конструкторы и вообще голову не забивать. Ещё можно в сторону ServiceLocator посмотреть, в контексте безопасности это тоже самое, но код писать проще, ибо не нужно постоянно лезть в God-object с эвентами. Вообще разных решений миллион, но они, в основном, избыточный для маленьких проектов.
Делаю что то похожее и есть проблема, в определенный момент не можешь придумать название нового евента на похожие по имени (но разные по функционалу) события в игре 😂 не плохо было бы затолкать в какой нибудь дикшинари эти евенты и по имени их вытаскивать. Получится динамическая шина в которой можно регистрировать евенты и нужные ребята по имени смогут туда подписаться и посматривать изменения, будь то квест на сбор определенных предметов на время или ui очки подсчитывает, или инвентарь смотрит что потратили и тд. И вся красота в том что если евента нет в шине то сущность просто живет и ни чего не делает, потому как не подписалась. Тут и модульность любимая и зависимости отвалятся. И интерфейс с ридонли тоже пригодиться. Но списочек с именами квестов придется где то держать в табличке, что бы через недели две не забыть что нарегистрировал 😂
Да, можно и так! Мы говорим про идею, про паттерн, тонкости - дело наживное) Можно сделать динамическим на словаре, правда тогда и наименования событий надо хранить где-то в статике, чтобы память не потекла ручьем)
Это все хорошо до момента, когда тебе нужно добавить яблоко в инвентарь в UI четко после анимации его собирания, а вот добавить в модель и отправить аналитику сразу по клику) представляю, сколько там будет ивентов на это яблоко, а еще в какой спагетти коллбэк хэлл это все превратится, если добавится, условное диалоговое окно в этом процессе или что-то типа того))
Вроде бы и да, но не понятно, а где вообще это должно использоваться) тут теряется вообще ответственность, все могут делать всё. + Появляются рэйс кондишны, потому что если на ивент будет более одного подписчика - в какой-то момент они поменяются местами и все полетит. Т.е. контроля над исполнением тоже нет. Я в этом паттерне вижу только рассадник багов) либо нужно будет на каждый чих наделать ивентов и контролировать, в каком порядке это все происходит. + Ещё добавьте сюда асинхронные IO операции, которые тоже могут начаться по одному из таких вот триггеров, в итоге тот, кто ивент этот вызвал никогда не узнает, закончилась ли размазанная по времени асинхронная фигня, которую кто-то та где-то написал) начнут писать WaitDelay(1s) и все такое))
Объясню как я понял , если у нас есть множество объектов на одном уровне, то есть они не на уровень выше и в следствие этого не должны знать друг о друге то ивентбас служит промежуточной связью между ними , что помогает не переплетать их тем самым руша архитектуру
я хоть и учусь еще, но и без комментаторов заметил, что в этом подходе что-то не так, особенно в моменте, когда любой может дать и любой может взять) в любом случае было бы очень здорово, если бы автор уделял хотя бы минуту разбора на то, когда стоит применять, а когда нет(сугубо по опыту и для общих случаев, понятное дело, что все равно это все индивидуально)
Просматривается некоторая параллель с системой сигналов и слотов в Qt. Только в Qt нет никакой централизации обработки этих сигналов, кто угодно может их испускать и кто угодно ловить (главное прописать кто на что и как должен реагировать). В итоге вся программа может быть насквозь пронизана этими связями, и если проект достаточно большой, в нем становится очень тяжело ориентироваться.
Имеем god-object, о котором все знают и от которого все зависят. Т.е. ни о какой изоляции компонентов уже речи не идет. Возможно, имеет смысл создать условно "шину", которая сама будет подписываться на события компонентов-источников и дергать методы компонентов-подписчиков. Тоже спагетти, но хоть сами компоненты не будут зависеть от шины. Здесь хоть и интерфейс, но это всё равно зависимость, которая не всегда нужна.
@@andrey_aka_skif в божественных объектах не плохие сами по себе. Антипаттерн может спокойно быть паттерном, как и паттерн в определённых ситуациях может стать антипаттерном.
Это полухак. То есть вроде и паттерн, но если можно обойтись без него - лучше обойтись без него. Мы оцениваем такие вещи на реальных проектах, нельзя заранее сказать, плохой паттерн или не плохой. Знай, что он есть, как можно применить, и однажды, когда тебе скажут сделать игру за 1.5 дня, ты его вспомнишь, вы вместе всплакнете, и сделаете игру в срок
@@titanovsky человек размышлял о минусах подхода. Я продолжил мысль. Сам подход шины событий используется часто. В тех же микросервисах. Хоть это и не прямой аналог.
Обычно event bus как-то глобально используют, и хочется увидеть реализацию, где можно из любого класса триггернуть и подписаться, без монобехов. В том смысле что bus один и все через него работают, типа zenject event bus. Данный пример интересен, но практически не очень полезен, тема, как мне кажется не раскрыта))), но автору виднее...
Отличный паттерн, идея плавала на поверхности, но самостоятельно в голову не пришла. Большое спасибо.
Не ожидал, что будет понятно с первого просмотра. Спасибо, очень хорошо объяснил идею)
Геймдев который мы заслужили. Спасибо большое ❤
Полезные видосы у тебя, спасибо за работу. Хотелось бы ещё послушать про визуал в юнити: шейдеры, слои отображения, канвасы, работа с камерой, свет в 2d и 3d, создание UI. Наверняка, у тебя есть чем поделиться в этой области.
Спасибо за видео. Надеюсь постепенно начну применять
Ооо, спасибо за еду) будем разбираться. Лайк!
- Раз уж тут люди говорят о болячках паттерна, то стоит упомянуть решение - просто создать дополнительный слой абстракции, который отнимет у подсистем работу подписки и возьмёт её на себя. Вуаля, код стал независемее, но труднее для понимания. Какое из зол меньшее, пускай уже каждый решит сам
Все верно!
Спасибо за видос, я что-то похожее делал, но систему назвал Hook.
Ооо новое видео
Спасибо
Чай заваривать не буду. Надеюсь, под макароны с котлетой тоже зайдет.
Таким образом можно и тригеры в интерфейс выделить. Но в целом, есть ощущение, что если используется такая шина, то где-то что-то плохо спроектировано.
Любой паттерн хорош или плох применением. В совсем маленьком проетке шина будет лишней, большой она превратит в спагетти, а для чего-нибудь среднего - как раз.
Плюс шины событий в том, что она экономит время разработчика, если тот знает где её применять. В итоге можно не морочить голову сложными связями, а сделать по-простому и всё будет прекрасно работать.
@@ichbinschlange все правильно, любое решение - это трата ресурсов, и тому, кто эти ресурсы выделяет (человеко-часы = деньги) решать, какой вариант будет оптимальным)
@@ichbinschlange
А что можно использовать в том же маленьком проекте для событий? Не подскажете? :с
@@cmep4359, всё строго индивидуально. Если проект учебный и опыта работы с шиной нет - отличный повод его получить, если проект совсем маленький и подразумевактся, что так и останется - просто покинуть всё нужное через конструкторы и вообще голову не забивать. Ещё можно в сторону ServiceLocator посмотреть, в контексте безопасности это тоже самое, но код писать проще, ибо не нужно постоянно лезть в God-object с эвентами.
Вообще разных решений миллион, но они, в основном, избыточный для маленьких проектов.
@@cmep4359
Можно попробовать использовать паттерн медиатор
Делаю что то похожее и есть проблема, в определенный момент не можешь придумать название нового евента на похожие по имени (но разные по функционалу) события в игре 😂 не плохо было бы затолкать в какой нибудь дикшинари эти евенты и по имени их вытаскивать. Получится динамическая шина в которой можно регистрировать евенты и нужные ребята по имени смогут туда подписаться и посматривать изменения, будь то квест на сбор определенных предметов на время или ui очки подсчитывает, или инвентарь смотрит что потратили и тд. И вся красота в том что если евента нет в шине то сущность просто живет и ни чего не делает, потому как не подписалась. Тут и модульность любимая и зависимости отвалятся. И интерфейс с ридонли тоже пригодиться. Но списочек с именами квестов придется где то держать в табличке, что бы через недели две не забыть что нарегистрировал 😂
Да, можно и так! Мы говорим про идею, про паттерн, тонкости - дело наживное) Можно сделать динамическим на словаре, правда тогда и наименования событий надо хранить где-то в статике, чтобы память не потекла ручьем)
Это все хорошо до момента, когда тебе нужно добавить яблоко в инвентарь в UI четко после анимации его собирания, а вот добавить в модель и отправить аналитику сразу по клику) представляю, сколько там будет ивентов на это яблоко, а еще в какой спагетти коллбэк хэлл это все превратится, если добавится, условное диалоговое окно в этом процессе или что-то типа того))
Такое в EventBus в принципе не должно попадать) я имею ввиду мешанину в виде секвенций визуала, там это просто не нужно)
Вроде бы и да, но не понятно, а где вообще это должно использоваться) тут теряется вообще ответственность, все могут делать всё.
+ Появляются рэйс кондишны, потому что если на ивент будет более одного подписчика - в какой-то момент они поменяются местами и все полетит. Т.е. контроля над исполнением тоже нет.
Я в этом паттерне вижу только рассадник багов) либо нужно будет на каждый чих наделать ивентов и контролировать, в каком порядке это все происходит.
+ Ещё добавьте сюда асинхронные IO операции, которые тоже могут начаться по одному из таких вот триггеров, в итоге тот, кто ивент этот вызвал никогда не узнает, закончилась ли размазанная по времени асинхронная фигня, которую кто-то та где-то написал) начнут писать WaitDelay(1s) и все такое))
Объясню как я понял , если у нас есть множество объектов на одном уровне, то есть они не на уровень выше и в следствие этого не должны знать друг о друге то ивентбас служит промежуточной связью между ними , что помогает не переплетать их тем самым руша архитектуру
я хоть и учусь еще, но и без комментаторов заметил, что в этом подходе что-то не так, особенно в моменте, когда любой может дать и любой может взять) в любом случае было бы очень здорово, если бы автор уделял хотя бы минуту разбора на то, когда стоит применять, а когда нет(сугубо по опыту и для общих случаев, понятное дело, что все равно это все индивидуально)
Просматривается некоторая параллель с системой сигналов и слотов в Qt.
Только в Qt нет никакой централизации обработки этих сигналов, кто угодно может их испускать и кто угодно ловить (главное прописать кто на что и как должен реагировать). В итоге вся программа может быть насквозь пронизана этими связями, и если проект достаточно большой, в нем становится очень тяжело ориентироваться.
Блин. Не могу обьяснить почему, но есть странно ощущение, что это не самая хорошая практика... Но может это и не так.
Имеем god-object, о котором все знают и от которого все зависят. Т.е. ни о какой изоляции компонентов уже речи не идет. Возможно, имеет смысл создать условно "шину", которая сама будет подписываться на события компонентов-источников и дергать методы компонентов-подписчиков. Тоже спагетти, но хоть сами компоненты не будут зависеть от шины. Здесь хоть и интерфейс, но это всё равно зависимость, которая не всегда нужна.
@@andrey_aka_skif в божественных объектах не плохие сами по себе. Антипаттерн может спокойно быть паттерном, как и паттерн в определённых ситуациях может стать антипаттерном.
Это полухак. То есть вроде и паттерн, но если можно обойтись без него - лучше обойтись без него. Мы оцениваем такие вещи на реальных проектах, нельзя заранее сказать, плохой паттерн или не плохой. Знай, что он есть, как можно применить, и однажды, когда тебе скажут сделать игру за 1.5 дня, ты его вспомнишь, вы вместе всплакнете, и сделаете игру в срок
Так и есть, потом не распутаешь все эти связи между десятками и сотнями триггеров и подписчиков.
@@titanovsky человек размышлял о минусах подхода. Я продолжил мысль. Сам подход шины событий используется часто. В тех же микросервисах. Хоть это и не прямой аналог.
Я не понимаю, почему EventBus создается в самом объекте EventBusExample. Это как-то совсем не логично мне кажется.
Так это ж просто для примера
Спасибо. В чём разница с брокером сообщений, сходу не соображу.
Обычно event bus как-то глобально используют, и хочется увидеть реализацию, где можно из любого класса триггернуть и подписаться, без монобехов. В том смысле что bus один и все через него работают, типа zenject event bus. Данный пример интересен, но практически не очень полезен, тема, как мне кажется не раскрыта))), но автору виднее...
Что за цензура на 6:26?
оО, интересно, интересно! Это не часть монтажа, если что
Ютуб заблюрил плохой код. Такое на ютубе нельзя показывать.
Сорян, бро, но я нихера не понял. Но спасибо в любом случае, попробую разобраться