P
Как заполнить? Через Switch?
Эмм, зачем там Switch?
Size: a a a
2020 November 05
Бд
мне надо генерить на сервере, сохранять в бандл, отдавать клиенту, и желательно не хранить в оперативке явно на клиенте. если хранить полученные от сервера меши в оперативке, то будет ад. а юнька под капотом, как я понимаю, оптимизирует хранение ассетов и их динамическую подгрузку. если нет - тогда вопрос снимается, ибо десериализовать не проблема
А почему бы и не ассетом передавать в таком случае ?
МР
Спагетти код. Гугли/учи ООП. А именно абстракцию. Делегаты туда-же
P
new Dictionary<State, string>()
{ { State.SearchingWater, "Walking"}}
{ { State.SearchingWater, "Walking"}}
P
new Dictionary<State, string>()
{ { State.SearchingWater, "Walking"}}
{ { State.SearchingWater, "Walking"}}
Можно даже не <State, string> а <State, Func<IEnumerator>>
P
Хотя здесь надо скорость выполнения чекнуть
IK
А почему бы и не ассетом передавать в таком случае ?
так как в ассете хранить несколько обьектов? по отдельности? тогда мешанина же буде. я думал в один бандл пару десятков таких структур кидать
W
Можно даже не <State, string> а <State, Func<IEnumerator>>
Ну вот на кой черт там вообще enum, ну?
Класс вызывающий метод уже знает что он хочет вызвать - он же знает нужный енам, верно?
Ну пусть прокидывает в метод делегат с функцией, который будет на той стороне корутиной запускаться.
Я бы вообще отдельный struct создавал под интерфейсом и его прокидывал в метод, по мне так симпатичнее выглядит.
Класс вызывающий метод уже знает что он хочет вызвать - он же знает нужный енам, верно?
Ну пусть прокидывает в метод делегат с функцией, который будет на той стороне корутиной запускаться.
Я бы вообще отдельный struct создавал под интерфейсом и его прокидывал в метод, по мне так симпатичнее выглядит.
P
Ну вот на кой черт там вообще enum, ну?
Класс вызывающий метод уже знает что он хочет вызвать - он же знает нужный енам, верно?
Ну пусть прокидывает в метод делегат с функцией, который будет на той стороне корутиной запускаться.
Я бы вообще отдельный struct создавал под интерфейсом и его прокидывал в метод, по мне так симпатичнее выглядит.
Класс вызывающий метод уже знает что он хочет вызвать - он же знает нужный енам, верно?
Ну пусть прокидывает в метод делегат с функцией, который будет на той стороне корутиной запускаться.
Я бы вообще отдельный struct создавал под интерфейсом и его прокидывал в метод, по мне так симпатичнее выглядит.
Чего
P
Ну вот на кой черт там вообще enum, ну?
Класс вызывающий метод уже знает что он хочет вызвать - он же знает нужный енам, верно?
Ну пусть прокидывает в метод делегат с функцией, который будет на той стороне корутиной запускаться.
Я бы вообще отдельный struct создавал под интерфейсом и его прокидывал в метод, по мне так симпатичнее выглядит.
Класс вызывающий метод уже знает что он хочет вызвать - он же знает нужный енам, верно?
Ну пусть прокидывает в метод делегат с функцией, который будет на той стороне корутиной запускаться.
Я бы вообще отдельный struct создавал под интерфейсом и его прокидывал в метод, по мне так симпатичнее выглядит.
Какой enum, кто знает, в какой метод, какой делегат
P
Нормально скажи, или код покажи
W
Нормально скажи, или код покажи
речь про ту хрень со свитчем?
или вы уже на другую тему перескочили?
или вы уже на другую тему перескочили?
K
new Dictionary<State, string>()
{ { State.SearchingWater, "Walking"}}
{ { State.SearchingWater, "Walking"}}
Я все понимаю, но когда ты будешь создавать этот Dict, ты точно такой же код будешь писать .
K
Почти такой же, без switch
K
Поэтому это похоже на over engineering
P
речь про ту хрень со свитчем?
или вы уже на другую тему перескочили?
или вы уже на другую тему перескочили?
Да
P
Я все понимаю, но когда ты будешь создавать этот Dict, ты точно такой же код будешь писать .
Суть в том, что так удобнее, и можно не вручную заполнять, если хорошо подумать
K
Суть в том, что так удобнее, и можно не вручную заполнять, если хорошо подумать
Создавать Dictionary и писать тоже самое, просто потому что ты не хочешь switch - это странное
A
Я за switch
K
Суть в том, что так удобнее, и можно не вручную заполнять, если хорошо подумать
Удобней вынести в какой-нибудь helper класс функцию с switch