Как избежать проблем с Execution Order?

Question

[ColdSpirit]

Добрый день. Всякий раз, когда создаю на юнити более чем несколько связанных компонентов, возникают проблемы, что один компонент пытается работать с другим, еще не проинициализированным компонентом. Это доходит до абсурда - бывает, всё работает нормально, а после перезапуска сыпятся баги, ибо юнити поменял порядок создания компонентов, и всё теперь нужно перепроверять.

Сам знаю 2 метода решения этой проблемы:

1. Использовать Script Execution Order Settings. Считаю это ужасным костылем для тех, кто не умеет планировать архитектуру. Ибо добавлять, утрирую, каждый созданный компонент туда и настраивать ему порядок - это не дело.

2. Написать собственный менеджер компонентов, который будет вызывать Init() компонента в определенном порядке, описанном в самом компоненте, как альтернатива Start и Awake. Этот метод недалеко ушел от предыдущего, разве что он более гибкий (каждому компоненту можно написать своё время запуска), и более удобный в использовании. Тоже костыль.

Интересует, какие методы решения данной и подобных проблем существуют не только для юнити, но вообще в программировании?
Как вы решаете эту проблему, каких правил и приемов придерживаетесь?

Answer 1

[Алексей Павлов]

Я в Awake использую инициализацию самого компонента, не используя связи с другими компонентами. А в Start все компоненты уже инициализированы, их можно использовать.

Компонент A в Start получает ссылку на компонент B. Не факт, что B уже вызвал Start и не имеет нужные ссылки. Тут два варианта
- B тоже должен иметь ссылку на A. Тогда A может передать себя в B (до вызова B.Start).
- B должен иметь ссылку на компонент C. Тут могут быть проблемы.

Чтобы такие связи были независимы от порядка, то каждый компонент в Awake должен поместить себя (зарегистрироваться) в какой-то контейнер, через который в Start в любом компоненте можно получить нужную ссылку.

Контейнером может быть
- статическое поле класса (если компонент планируется только один, то получается типа полу-синглтон - поле устанавливается в Awake, а потом используется отовсюду во время Start и после)
- специальный список в родителе (если компонент не одиночка)
- IoC-контейнер

Comments

[ColdSpirit]

Спасибо, про Start->Awake хороший метод, правда он вроде не работает когда много зависимых друг от друга синглтонов, но, мне кажется, что это последствия плохого планирования.

Не совсем понял, для чего нужен список в родителе.
Совсем не понял как использовать IoC в юнити, попробую изучить этот вопрос поподробнее на досуге.

[Алексей Павлов]

ColdSpirit Решение проблемы в том, что всегда можно было найти ссылку на нужный компонент, тем или иным способом. Причём, после Awake этих компонентов. А так как мы (в общем случае) не управляем порядком пробуждения компонентов, то искать их надо в Start.

На самом деле, это древняя проблема. Юнити даёт методы типа GetComponent и FindObjectOfType, но с ними не всегда удобно, а иногда и вообще нельзя (о чём вы и спрашиваете в вопросе). Но остаётся старый добрый "до-юнитевый" путь - вручную указывать ссылки (через конструкторы и прочее, но у MonoBehavior нет конструктора).

>Не совсем понял, для чего нужен список в родителе.
Если компонент на сцене один, то делаем синглтон. Но бывает так, что компонент может быть не один, и нужны ссылки на каждого. Тогда каждый компонент при Awake должен куда-то себя зарегистрировать. В обычное статическое поле класса нельзя. Можно либо в класс сделать статическое поле со списком, либо у родителя сделать класс-холдер с этим списком, либо тот же список в отдельном менеджере.

>Совсем не понял как использовать IoC
Я знаю про StrangeIoC и Zenject, наверняка есть и другие. Они как-то там пытаются понять, как работать с MonoBehavior-ами. Сам я с ними не работал.

Также, мне нравится разделять гейм-логику и юнити - гейм-логика в отдельном месте, где нет доступа в юнити. А Юнити работает только как презентация. См. статьи 1 и 2

[ColdSpirit]

Прочту, спасибо! Сейчас изучаю Zenject, я так понял, там где-то в отдельном классе задаются зависимости классов, какие зависят от каких, а контейнер запускает инициализаторы этих классов в нужном порядке.

То есть это как менеджер компонентов, про который я упоминал в вопросе, только вместо сортировки компонентов по порядковому номеру, он будет сортировать их в соответствии с зависимостями, а потом запускать инициализаторы.

Я всё правильно понял?

[Алексей Павлов]

ColdSpirit, да, всё верно. Вначале вы указываете те классы, которые вы планируете искать через контейнер. И тогда он пытается разобраться, что и когда нужно инициировать, с учётом взаимных зависимостей.

Answer 2

[Alex Maximovich]

Я бы не полагался на Script Execution Order а использовал бы что-то вроде этого: https://refactoring.guru/ru/design-patterns/chain-...

Comments

[ColdSpirit]

Очень интересный паттерн! Правда я не понял, как его использовать в контексте порядка создания скриптов.

Допустим у нас есть объект Car, внутри 2 объекта - Engine и Fuel. При Start() автомобиль должен завестись.

В реализации Car даст команду Engine, тот в свою очередь запросит данные из Fuel. Но это произойдет только при хорошем раскладе. В плохом раскладе объекты не будут проинициализированны в момент команды.

Как применить этот паттерн в данном примере?

[Alex Maximovich]

ColdSpirit, А нужен ли он в данном примере? По вашему описанию у вас идет просто взаимодействие моделей данных. И нет никаких проблем дернуть методы ваших сущностей так как вам надо. На сколько я понимаю, у вас проблема в том, что бы на момент вызова методов Car существовали все объекты.

[ColdSpirit]

Alex Maximovich, именно так.

Я так понял мы немного о разных вещах говорим, Script Execution Order ведь можно использовать для инициализации объектов перед инициализацией зависящих от них объектов, а можно и для запуска компонентов в определенном порядке. Способ один, но цели разные.

Я имел ввиду первый случай, а вы, я так понял, имели ввиду второй случай.

[Alex Maximovich]

Скорее всего так. Но можно цепочку команд использовать. Просто По факту у нас будет очередь, которая состоит из команд которые инициализируют нужные сущности в нужном порядке. Что-то типо :

var queque = new CommandQueque();
queque.Add(new InitCarCommand());
queque.Add(new InitEngineCommand());
queque.Add(new CheckFuelCommand());

queque.Run();

Но это не совсем то судя по всему.

[ColdSpirit]

Alex Maximovich, ну, для некоторых случаев такой метод пойдет. Для инициализации цельных объектов, как автомобиль например. Сейчас изучаю IoC-контейнеры, кажется, что они то же самое делают, только более глобально и абстрактно.

[Alex Maximovich]

ColdSpirit, Порядок инициализации так или иначе останется на вашей совести. Единственное что через IoC Di контейнеры будете зависимости пробрасывать.

Answer 3

[Griboks]

Используйте менеджер зависимостей, внедрения зависимостей. Пишите скрипты, в которых не может возникнуть подобных ошибок. Настраивайте зависимости в редакторе (скрипты) или в инспекторе.

Comments

[ColdSpirit]

Пишите скрипты, в которых не может возникнуть подобных ошибок.

Нельзя просто так взять, и написать валидный код =) Для этого нужен опыт и методология.

Настраивайте зависимости в редакторе (скрипты) или в инспекторе.

Имеете ввиду ссылки на компоненты пробрасывать через редактор, а не через GetComponent? Чем это будет лучше чем GetComponent?

[Griboks]

ColdSpirit, не будет null.

[zhaparoff]

+1 за DI.
Пусть за вас контейнер думает, какие зависимости надо создавать в каком порядке.
Единственный подводный камень при таком подходе - возможное существование циклических зависимостей - вот это придется лечить перепланировкой архитектуры, т.к. это явный bad design.