Про «Наблюдателя»
https://www.youtube.com/watch?v=0wVF68QZrtQ

Хорошее видео, но на самом деле депенденси хелл чутка преувеличен. Потому что тут вопрос реализаций представленной в видео. Да паттерны обладают разными недостатками. Но тут мне не совсем нравится логика регистрации объектов в наблюдателе. Хотя в видео по сути поднимается проблема депендеси хела со всякими менеджерами типа звука.

И в целом берется небольшая проблема прямолинейной реализации. С миллионами зависимостей, узкими точками отказа и так далее. На самом деле это бывает даже не так критично, когда вы пишете не движок, не библиотеку и не фреймворк :)

Разберем на примере менеджера звука. Есть про менеджер звука знают объекты визуализации и объекты игровой логики, это казалось бы потенциальная точка отказа. Но мы не на сервере с сложной реализацией сервиса. Менеджер звука обычно это весьма условно стейтлесс штука (точнее её стейт не особо меняется), и она по сути просто что вызывает «системные вызовы» воспроизведения звуков. По крайней мере в той точке где миллиард зависимостей. Если зависимости не меняют состояния, обращаются в точку которая не может отказать и вызывают довольно тупые методы — там сложно создать себе проблемы. Это происходит в других случаях, где множество зависимостей меняют состояние объекта в не пойми каком порядке.

Но базово как этой проблемы избежать? Вот у нас есть звук при спауне, звук при сборе и так далее. И тут нам помогает композитная система Unity компонент. И абстрактные Unity события. Система компонент позволяет по юнити событиям делать подобные вызовы при этом не зная о контексте остальной системы. Да и в целом это работает специфично. Потому что это как раз ведет нас к разнице подходом Config-First, Code-First и так далее далее.

Но и у них есть своя цена. Код ферст всегда позволяет почти всегда быстро находить проблемы, так как там нет контрактов, которые не зафиксированы в коде. Конфиг ферст всегда имеет какой-то внешний абстрактный контекст и часто требует документации.

Для примера с тем же пресловутым звуком. У вас есть понятное место в коде где по логике вызывается сбор кристаллов. И вы вызываете там звук сбора кристалла. Всё явно и очевидно. Альтернативное решение без лишних зависимостей. У вас есть компонента которая в OnDisable вызывает звук по айди. Айди сериализованное поле. Вам нужно повесить на префаб кристалла эту компоненту и прописать айди соответвующего звука. И это уже некий абстрактный контракт не зафиксированный кодом.

А видос рекомендую посмотреть. Так как понимать как можно играться с архитектурой проекта полезно. И автор говорит дельные вещи. Что в конкретном примере это не критикал — это неважно. Так как когда создаешь подобные материалы трудно подобрать пример который подсвечивает все нюансы.

#новости #мнение