Информация об изменениях

Сообщение Re: "Гибкий" конструктор для инициализации объекта класса (а от 25.08.2023 0:26

Изменено 25.08.2023 0:34 Sm0ke

Re: "Гибкий" конструктор для инициализации объекта класса (а
Здравствуйте, zelenprog

Желательно разложить всё по полочкам

Как понимаю три пункта работы приложения:
* Инициализация
* Работа
* Завершение



Задача первого пункта

Подготовить к работе все ресурсы.

Вот от них кажись и надо плясать. Какие виды ресурсов для работы нужны? (model_3d, music_background, etc)



Для каждого Делаем класс: ресурс такой-то

Для формирования этого ресурса есть параметры

можно сложить эти параметры в структуру (обычно без методов): params_init_ast (или что там)
* Каждому набору параметров формирования своя структура.

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




Создание объекта с параметрами формирования в некоторых случаях удобно поручить отдельному классу.



Если вдруг окажется, что класс ресурса нуждается в общении с другими классами (назовём "вычислители"), то есть от них зависит
То почему бы не добавить этих "вычислителей" как поля для структуры params_
Да капитан, параметр ясен перец может быть классом.

struct params_car_holder (text name, float size, agent orange)

// метод-аксесор
params_car_holder::get_age() { return this.orange.calc(this.size) }




Что по файлам? Хорошо ли отделить по разным классам: А логику загрузки данных от Б набор ресурсов для хранения и обработки?
Когда загрузчики более не нужны — некоторые можно выгрузить из оперативки. Хотя во втором пункте бывает нужно что-то подгружать)



Система
  Ресурсы
  Обработчики


В таком раскладе обработчиков можно динамически подменять налету.
Типо когда в игре по сети теряется соединение и происходит переход в автономный режим.
Сорян, пример надуманный, я не работал в гейм деве.
Re: "Гибкий" конструктор для инициализации объекта класса (а
Здравствуйте, zelenprog

Желательно разложить всё по полочкам

Как понимаю три пункта работы приложения:
* Инициализация
* Работа
* Завершение



Задача первого пункта

Подготовить к работе все ресурсы.

Вот от них кажись и надо плясать. Какие виды ресурсов для работы нужны? (model_3d, music_background, etc)



Для каждого Делаем класс: ресурс такой-то

Для формирования этого ресурса есть параметры

можно сложить эти параметры в структуру (обычно без методов): params_init_ast (или что там)
* Каждому набору параметров формирования своя структура.

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




Создание объекта с параметрами формирования в некоторых случаях удобно поручить отдельному классу.



Если вдруг окажется, что класс ресурса нуждается в общении с другими классами (назовём "вычислители"), то есть от них зависит
То почему бы не добавить этих "вычислителей" как поля для структуры params_
Да капитан, параметр ясен перец может быть классом.

struct params_car_holder (text name, float size, agent orange)

// метод-аксесор
params_car_holder::get_age() { return this.orange.calc(this.size) }




Что по файлам? Хорошо ли отделить по разным классам: А логику загрузки данных от Б набор ресурсов для хранения и обработки?
Когда загрузчики более не нужны — некоторые можно выгрузить из оперативки. Хотя во втором пункте бывает нужно что-то подгружать)



Система
  Ресурсы
  Обработчики


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