Комментарии 14
Все эти Message/Signal Bus это, конечно, замечательно decoupling, тестируемость и так далее по списку, но есть одно большое НО. Я поддерживал два проекта с подобной архитектурой и видел ещё несколько подобных. У них есть одна большая проблема, в них абсолютно невозможно разобраться (по крайней мере эта проблема была на всех проектах, с которыми я работал, возможно, кто-то готовит это лучше):
- Cигналы летят чёрти куда и чёрти когда, слишком высокая когнитивная нагрузка на работу с таким кодом, особенно, если его писал не ты (тем кто это писал, конечно же, всё нравится)
- Невозможно понять что нужно слушать/триггерить, документация далеко не всегда есть на проекте, опять же нужно идти и смотреть по коду. С интерфейсом для View, у которой есть понятный интерфейс с обычными событиями работать в разы проще.
- Сигналы вообще ничего не гарантируют — не гарантирует, что View точно триггерит такой сигнал, не гарантирует что он значит то, что ты ждёшь.
- Невозможно управлять порядком, в котором отрабатывают подписчики (если их несколько). В местах, где это необходимо приложение начинает обрастать костылями, что опять-таки увеличивает когнитивную нагрузку.
- Разработчики слишком увлекаются сигналами и вместо того, чтобы вернуть какой-то результат триггерят сигнал (апофеоз такого подхода кода вида 'void Login()', а как получить результат — лезь в код и ищи сам)
- Как продолжение двух предыдущих пунктов, возникают ситуации, когда код настолько завязываются на сигналы, что вся гибкость подхода испаряется.
Меня тоже сначала привлекал такой подход, но поработав с парой проектов в подобном стиле я понял, что оно того не стоит. Может квалифицированные разработчики и могут приготовить это всё хорошо, но то, что видел я, вгоняет исключительно в депрессию.
Зависит от типа игры, этапа разработки и требований, на самом деле. Я бы сначала написал слой модели и сервисов, покрыл бы их тестами, а потом бы уже думал о том, через что связывать это всё с View (на схеме в статье предлагается не самое лучшее решение сделать анемичную модель и перенести бизнес логику в контроллер, я бы такого избегал). Откуда начинать писать модель не особо важно, можно взять какую-то понятную сущность, начать писать его логику, а всё остальное скрывать за абстракцией и мокать
Если волнует непосредственно отношение с view, то у нас в студиях есть два основных подхода: HMVC и ECS.
А вообще все подобные проблемы возникнут на любом более менее крупном проекте, который писали много программистов и в котором много сущностей. При любой парадигме. Всё равно надо будет сидеть и въезжать что откуда ).
Вопрос какой уровень въезжания нужен, даже код написанный на синглтонах разобрать проще, а в подходах, которые используются у нас в студиях разобраться ещё проще.
Расширяемая и удобная в сопровождении архитектура игр на Unity