uint идентификаторы

[caseyryan]

Ну я думал завести в классе-справочнике константы идентификаторов и при запуске программы один раз раздать им значения из генератора, а потом уже до самого конца их использовать:

Я понял. Об этом и говорю. Вот этот код у тебя будет выполняться при каждом запуске программы. То есть хоть ты и задал это как константу, но по сути это динамическое значение. Если в твоем генераторе поменяются какие-то данные (а они по-любому поменяются), ты получишь каждый раз разные ID для одних и тех же айтемов. Если задача просто в том, чтобы у разных айтемов были уникальные айди, то ок, все будет работать. А если задача сохранять что-то в базу данных, то это фиаско, так как в базе будут одни айдишники, а в программе уже другие при каждом запуске.
Я бы лучше их руками вписал, чтобы они были реальными константами и никогда не менялись

[Appleman]

Вот! Я как раз хотел ещё спросить в продолжение темы. Смотрите. Всё, что мы сейчас обсуждаем - это идентификаторы в Модели. Но у наших объектов ещё есть ID для Вью, плюс в силу специфики моего жанра (текстовый RPG/квест), ещё и ID подбора фраз для языковой системы.

Изначально я сразу назначал строковые ID и использовал их везде (Модель, Вью, язык) в неизменном виде. Потом начались усложнения. Например, в зависимости от пола ГГ фраза может звучать по-разному: "пришёл"/"пришла" и т.д. Я начал к идентификаторам добавлять пол персонажа (значение uint). Далее, по мере усложнения Модели и добавления функционала, я понял, что некоторые мои ID уже не так хорошо отражают суть и требуют уточнения. Но чуть только я их тронул, сразу "поехал" язык. Короче, я запутался.

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

static public function getIconID(statusID: String, genderID: uint) : String
		{
			if (_iconsSync[statusID + genderID as String]) return _iconsSync[statusID + genderID as String];
			else if (_iconsSync[statusID]) return _iconsSync[statusID];
		}

В общем, думаю, суть вопроса понятна. Как этот бардак организовывать!?

[Tails]

По поводу он/она, вот, буквально на днях написал простой, текстовый интерпретатор. Суть его работы в том, что он обрабатывает скриптовые вставки в тексте. Наподобие: "Сегодня {%sex|он поехал|она поехала%} на работу." (Жирным выделена скриптовая вставка) После обработки, на её место подставляется "он поехал" или "она поехала".

Если интересно, могу скинуть. Там всего один класс, правда, написан на haxe.

[Wolsh]

Сообщение от Tails

А мне 16x числа напоминают дизайнеров. Они цвета в нём обычно хранят.

Ну да, программисты-то хранят цвета в виде "Lite Pale Veronese Green Earth"..
"начинай с 0, потом 1.."
Освежу в памяти, как кодируется цвет в HEX:
E2F0AE это E2.F0.AE, то есть R.G.B. Хотя вцелом это какое-то астрономическое число в десятиричной системе, здесь используется именно кодирование, то есть значение знака зависит от его позиции. В каждой из трех позиций находится число "всего лишь" от 0 до 255, то есть 256 значений.
Итак, у нас есть реестровые номера вида 00.11.22.
256 разделов по 256 классов по 256 подклассов.
Например, так: Оружие.Мечи.Эльфийский меч. Или: Броня.Кирасы.Мифриловая кираса.
А если мало трех разделов, то флэш поддерживает и 32 бита (ARGB для цветов), так что HEX-ID может содержать 4 указателя разделов.
А то навыдумывали тут, от ноля и до столба, генератор случайных чисел и т.п.
Не вводите людей в заблуждение. Упорядочить можно все, было бы желание. Ну, и кучу можно создать из всего, а як же шь.

[Tails]

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

[Wolsh]

Ну как бы я тоже в самом начале рекомендовал такой подход, объясняя тем, что по числовым идентификаторам можно легко создавать таблицы (массивы), а не строковые списки (по алфавиту чтоли будешь искать?). Если использовать раздельный HEX, то можно организовать все в массив 256 ячеек, в кождой ячейке которого массив 256 ячеек, в каждой ячейке которого.. и тд. И сущность с ID 0xE2F0AE будет доступна как ITEMS[0xE2][0xF0][0xAE]. При этом сами вложенные массивы можно расписывать отдельно и собрать конечную библиотеку "в конце", типа
const SWORDS:Array = [ElvenSword, GlassSword, IronSword, RustIronSword, ImperialSword ..];
const WEAPONS:Array = [SWORDS, ARROWS, BOWS, KNIFES, MACES ..];
const ITEMS:Array = [ARMORS, WEAPONS, CLOTHS, FOODS, JEWERLY, TOOLS, MATERIALS, DRINKS ..];
(ну, более упорядоченно по смыслу конечно)))
Но тогда не было понятно, нужно ли такое в данной игре. Да и сейчас непонятно))

[Appleman]

Wolsh, не ну это круто конечно! Я за уже почти 15 лет плотного занятия 3D-графикой никогда даже не пытался в таком ключе интерпретировать систему записи цветов RGB. Вон он - образ мыслей программиста.

Уточни, пожалуйста, другое. В какой-то теме ты уже приводил как раз такую запись значения и все уже обсуждали цвета. Но оно было введена "от руки", т.е. напрямую что-то типа 0x604181. И это не было результатом работы какого-то кода. Значит ли это, что подобный подход - использовать вложенные массивы-справочники - реализуется не непосредственно в создаваемой программе, а где-то "на стороне"?

И ещё за общими рассуждениями замылился мой второй вопрос. Что думаете на счёт использования справочников синхронизации между Моделью и Вью?

Добавлено через 13 часов 3 минуты
Друзья, я с позволения конкретизирую вопрос. Давайте посмотрим под углом любимой всеми нами MVC на конкретном примере

Вот смотрите. У меня есть такая штука как варианты действия. Например, если игрок выбрал "ударить", то следом игра его спрашивает, как: "слабо", "сильно", "со всей дури". Это экземпляры отдельного класса. Содержат модификаторы к значениям действия (если "сильно", то точность падает, а усталость возрастает и т.п.). Чтобы выводить их в диалог, предусмотрены строковые ID, которые передаются во Вью в метод формирования меню. Он лезет в класс LanguagePack и вытаскивает по ID конкретные фразы на нужном языке.

Чтобы не утонуть в многочисленных фразах, языковой файл иерархически разбит на секции. ID секции принимается первым обязательным параметром метода подбора фразы. Таким образом, для подбора конкретного лэйбла кнопки с вариацией запрос выглядит следующим образом:

var label: String = LanguagePack.getSinglePhrase(LanguageIDs.SECTION_AV_BUTTONS, variation.variationID);

Теперь я добавил игровые предметы. И потребовалось сделать принципиально новые вариации действий. Например для действия "лечиться" предстоит выбрать, чем: боярышником или коньяком. В Модели всё получилось прекрасно: унаследовался от VariationEntity и переписал геттер, чтобы вместо фиксированного перечня он подбирал вариации по предметам нужного типа из наличия. В общем, всё "срослось". А вот во Вью затык! Ведь лэйбл для фразы теперь нужно подбирать не из секции наименований вариаций (SECTION_AV_BUTTONS), а из секции названий предметов (SECTION_ITEM_NAMES). Вью "не знает" и "не может знать" этого.

Альтернативы мне видятся такие:
1. Инкапсулировать подбор лэйбла прямо в классе вариации. Ведь каждый наследник точно "знает", с чем он работает, и может сам обратиться к языковому файлу, чтобы приготовить и записать для себя лэйбл. А метод подготовки меню - просто его вытаскивать и лепить на кнопочку, не приходя в сознание. Но мне этот подход почему-то кажется каким-то "неMVC-шным". Я старался, чтобы на уровне Модели (а создание и подбор вариаций действия - прерогатива Модели, без сомнения) вообще не фигурировали никакие конечные выводимые объекты, будь то тексты или картинки.
2. Добавлять логику в класс подбора фраз. Собственно то, о чём я раньше спрашивал в этой теме. Чтобы некий отдельный метод (или целый Класс) получал ID фразы из Модели (вот тут как раз будет неважно, String или 16х uint или что-то ещё) и по нему выдавал нужную фразу. Здесь главная проблема - это контекст. Как видно из примера (я для этого его так подробно и описывал), может быть много контекстов. Их формализация и передача в метод-посредник - отдельный геморрой с непонятными перспективами.

Застрял я конкретно. Пока не решу, боюсь дальше двигаться, ибо по мере добавления функционала проблема усугубляется. Просьба прокомментировать мои варианты. Спасибо.