Циркулярное руководство по Unity Tutorial

Question

Я довольно новичок в Unity, поэтому я смотрел некоторые учебные пособия, и в одном из них они сделали такой шаблон:

GameController.cs

public class GameController : MonoBehaviour {

    [HideInInspector] public RoomNavigation roomNavigation;

    void Awake()
    {
        roomNavigation = GetComponent<RoomNavigation>();
    }
}

RoomNavigation.cs

public class RoomNavigation: MonoBehaviour {

    GameController controller;

    void Awake()
    {
        controller = GetComponent<GameController>();
    }
}

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

Answer 1

Здесь нет проблем

То, что ObjectA имеет ссылку на ObjectB и ObjectB , также имеет ссылку на ObjectA, что не означает ничего, кроме «они ссылаются друг на друга».

Информатика работает с двусвязными списками на протяжении десятилетий.

Не вызывает ли это проблемы со сборкой мусора?

Нет, потому что GC знает о таких вещах, если только это не наивная реализация GC, но C # .NET имеет хорошую (или, по крайней мере, не наивную) систему GC. Он не проверяет, имеет ли какой-либо объект какие-либо ссылки , он работает сверху вниз: Main имеет ссылку на GameObject, которая имеет ссылку SomeObject, которая имеет ссылку на ObjectA который имеет ссылку на ObjectB, который имеет ссылку на ObjectA (о, этот уже отслежен, двигайтесь дальше ...).

Среди других тактик, таких как помещение вновь созданных объектов в пул для периодической проверки на предмет еще живого состояния, и как только он некоторое время остается живым, он помещает его в пул, вероятно, еще живого, который проверяется менее часто. Или используя поле с именем isDead, которое будет помечено как истина деконструктором класса (это произойдет далеко внизу в базовом коде Unity на C ++), которое помечает объект для GC.

Если оба объекта станут изолированными (т.е. их родительский игровой объект будет уничтожен), они тоже будут уничтожены.

А как насчет проблем стиля кода или архитектуры программного обеспечения?

Возможно. Но это совершенно субъективно, а не по теме. Должны ли эти два объекта знать друг о друге? Могут ли они быть одним объектом вместо этого? У этих классов есть подтипы и они взаимозаменяемы?

Имейте в виду, что GameObject знает о Transform, а Transform уже знает о GameObject, и есть вполне законные причины, чтобы это было правдой.