YK
можно попробовать нужные зависимости в скрипты пропертями передавать
Size: a a a
2020 April 21
YK
тогда четко понятно к кому скрипт обращается
YK
в рамках сцены можно создать пустой обьект, на него повесить скрипт StateManager (например) которые будет уметь состояние хранить и пусть даже простые методы getState, setState как выше предлагали. Потом где надо в скриптах делаем проперти
public StateManager stateManager;и просто в редакторе проставляем его
AD
можно попробовать нужные зависимости в скрипты пропертями передавать
свойства тяжёлые сами по себе, представь если каждый скрипт будет иметь свойство по обращению к 5-6 другим скриптам, и так к примеру придется между 4 скриптами строить 6 связей строить, либо цепочкой передавать из одного в другой, а если нужно сначала в одном обработать, а потом в предыдущем? выйдет, что придется кэшировать большие объемы памяти
AD
в рамках сцены можно создать пустой обьект, на него повесить скрипт StateManager (например) которые будет уметь состояние хранить и пусть даже простые методы getState, setState как выше предлагали. Потом где надо в скриптах делаем проперти
public StateManager stateManager;и просто в редакторе проставляем его
ну, синглентон это и делает
YK
синглтон для стейта это моветон
YK
почему свойства тяжелые? это ж просто ссылка на класс
AD
в рамках сцены можно создать пустой обьект, на него повесить скрипт StateManager (например) которые будет уметь состояние хранить и пусть даже простые методы getState, setState как выше предлагали. Потом где надо в скриптах делаем проперти
public StateManager stateManager;и просто в редакторе проставляем его
получается, что данный синглентон есть той самой стейтмашиной
AD
почему свойства тяжелые? это ж просто ссылка на класс
в оптимизации .net советую избегать свойств
RM
свойства тяжёлые сами по себе, представь если каждый скрипт будет иметь свойство по обращению к 5-6 другим скриптам, и так к примеру придется между 4 скриптами строить 6 связей строить, либо цепочкой передавать из одного в другой, а если нужно сначала в одном обработать, а потом в предыдущем? выйдет, что придется кэшировать большие объемы памяти
Свойства создают лишний вызов с соответствующими последствиями. Но говорить, что они сложные в корне неверно
ЯС
в оптимизации .net советую избегать свойств
это именно в юнити? впервые слышу такое с точки зрения дотнета. Любой POCO объект через проперти делается
AD
Свойства создают лишний вызов с соответствующими последствиями. Но говорить, что они сложные в корне неверно
я говорила "тяжелее"
YK
в оптимизации .net советую избегать свойств
лол, компилятор раскрывает свойство в поле и методы геттер и сеттер, нету оверхеда
ЯС
я говорила "тяжелее"
"свойства тяжёлые сами по себе" вполне однозначно😝
YK
а в юнити для зависимостей вообще поля используются
AD
это именно в юнити? впервые слышу такое с точки зрения дотнета. Любой POCO объект через проперти делается
memory management .net under the hood, на 5ой или 7ой странице написано
ЯС
memory management .net under the hood, на 5ой или 7ой странице написано
в общем, в мире именно дотнета так никто не делает, все юзают свойства
ЯС
конкретно в юнити не знаю, в ней нет продакшен опыта
RM
в рамках сцены можно создать пустой обьект, на него повесить скрипт StateManager (например) которые будет уметь состояние хранить и пусть даже простые методы getState, setState как выше предлагали. Потом где надо в скриптах делаем проперти
public StateManager stateManager;и просто в редакторе проставляем его
Не вижу особой разницы между этим и синглтоном
AD
а в юнити для зависимостей вообще поля используются
да, поля это хорошо, я их и так часто юзаю, однако переодично возникает проблема того, что в одном скрипте нужно одно значение, которое нужно раскидать по 10 другим скриптам