Вопрос-ответ 3

Например, есть класс переключатель панелей юай. Где располагаешь скрипты в иерархии? Он бы находился на объекте канваса среди других компонентов, или на пустом отдельном объекте? Как ребенок канваса или как отдельный объект?

Скрины будут чуть ниже, так как ответ будет длинным. Тут важно понимать вот что. Я не люблю Code First подход. Вообще. Я считаю его неудобным. И дальше я объясню почему и схему организации используемую почти во всех проектах.

Менеджеры

Отвечая конкретно на на вопрос. Для меня класс переключатель экранов — это менеджер экранов. Я бы его обозвал каким-нить роутером, так как в будущем он может пригодится для функционала дип линок. Поэтому он лежал бы в [MANAGERS] из первого скриншота. Многие менеджеры — это монобехи, если им нужны Start, Awake или Update, которые лежат в отдельном объекте в сцене.

Я не люблю делать какой-то бусстрап скрипт или любую централизованную систему запуска приложения. Мне нравится когда по сути все "сервисы" или фичи имеют свой менеджер, свои реализации, свою инициализацию и т.п. И не запускаются из какой-то одной точки.

GUI

Интерфейсы же очевидно являются монобехами. Скрипты это обычно вроде UIPanel или типа того, которые управляют отрисовкой и вызывают методы или кидают события, которые реализует интерфейс. И тут хочется сделать важную ремарку. Я терпеть не могу в них Code First процесс. Особенно часто встречаемое AddListener на кнопки в гуе, вместо прокидывания через сериализацию Unity и вот почему.

Чем плох Code First? И зачем нужна такая организация?

Когда вы единственный разработчик системы, знаете свою систему и никому никогда не нужно её поддерживать. Пишите как чувствуете. А в остальных случаях давайте разберём такую вещь как расследование бага в неизвестной тебе фиче.

У вас баг, что по какой-то кнопке неверно что-то работает. Как проще всего локализовать проблему? Представим сложную панель и два случая. Баг причём визуальный и без логов, скажем вёрстка едет.

Случай первый. Кнопка подписана через сериализацию на то, что она запускает. Вы заходите в сцену. Проходите до того, чтобы инстанцировался нужный гуй. Находите кнопку и видите, что она вызывает.

Случай второй. У вас подписана в виджете в AddListener. Напоминаю, вы не знаете устройство системы. И допустим коллега, что её делал в отпуске или это легаси, и его уже нет в компании. Вы делаете тоже самое, смотрите все виджеты и скрипты в панели, пока не найдёте кнопку на которую будет подписка. И хорошо если по названиям нет дубликатов, чтобы не запутаться. Либо гадаете где она вызывается по IDE или логике названий. Либо самый длинный путь идти от точки входа подсистемы и разбираться где вызов именно этой кнопки.

Организация по "подпапкам" и т.п. выполняет ту же функцию. Как и строгие грамотные названия, организация ассетов. Всё нужно организовывать так, чтобы вам потом было удобно расследовать "что не так". И в целом разбираться в том, как работает проект. А благодаря редактору удобно это делать разрабатывая всё по схеме MVVM и используя все возможности визуального связывания с моделью.

Напоминаю, что интересующие вас вопросы можно задать тут.

#вопросы