Event Bus и расширяемые игры. Часть 1
В последнее время среди игровых разработчиков возрос интерес к паттерну "Шина Событий". Этот паттерн часто ругают за его тенденцию к "размыванию логики" и "скрытию зависимостей". Однако, несмотря на критику, полный отказ от этого паттерна также глуп как и написание кода в блокноте вместо специализированной IDE. В этой статье рассмотрим создание игр…
Медиатор/Посредник
А разве не Observer? Ну и вообще зачем надо 3 плагина ради этого городить если можно сделать простенький статический класс с двумя коллекциями делегатов и привязку событий делать на енамках. Моя простенькая реализация (подсмотренная на одном собесе пару лет назад и передопиленная до плагина в юнити)
https://github.com/noldowalker/CustomEventSystem
3 плагина не для этого
Zenject это DI контейнер, он не связан с шиной событий
DoTween для процедурных анимаций
Но согласен, это не совсем очевидно из статьи
А в целом, не хочу учить людей писать велосипеды. Если есть устоявшиеся фреймворки, то лучше пользоваться ими.
Иначе с тем же успехом веб разработчик может выпустить статью «напишем свой реакт»
В том числе и Observer, конечно
Но в своей сути любое увеличение числа промежуточных классов и разбивание зависимостей - это медиатор в первую очередь