Russian Qt Forum

Добрый день

Объект имеет обширный набор "параметров" организованных в виде дерева. Доступ к параметру осуществляется по уникальному ключу (ID), напр (псевдокод)

C++ (Qt)
const int DIFFUSE_ID = 2070;
...
Param * param = object->GetParam(DIFFUSE_ID);

Сам нод дерева (param) нужен редко, зато очень часто его значение, напр

C++ (Qt)
double value = object->GetParamValue(DIFFUSE_ID, currentTime);

Таких вызовов тысячи. Все работает, все хорошо. Но вот понадобилось дерево сделать динамическим, т.е. узлы могут добавляться и удаляться. С точки зрения дерева это выглядит так
Как лучше всего адаптировать имеющийся (не маленький) код к этому изменению?

Спасибо

не совсем понятно что меняется при удалении и добавлении узла
ведь есть указатель на объект и по нему получить можно параметр
чтото еще изменилось ?

Ткперь DIFFUSE_ID уже не является однозначным ключом. Напр Что должен делать объект чтобы получить значение не из первого а из второго узла "материал"?

Ну, или добавить ещё 1 параметр как "родителя", или сделать привязку к текущему узлу.

Как я вижу без изменения основных вызовов( добавляется только установка текущего параметра)

Или же вариант с добавлением параметра

Ну ещё можно зафигачить GetParamValue со значением по умолчанию для поддержки старого кода. Т.е. до первого найденного параметра DiffuseId

PS других вариантов, без масштабных изменений не вижу.

Число параметров нода "материал" - где-то от 100 до 200 (точно не мерял). Число вызовов этих параметров - тысячи. При этом механизм GetParamValue используется повсеместно, не только для материала.

"Адаптация" вовсе не означает "менять как можно меньше", да, хотелрсь бы, но др соображения могут быть более важны. Напр здесь главное - обеспечить надежность вызовов, нужно сделать так чтобы старое GetParamValue выдавало ошибку компиляции при обращении к параметру материала (но продолжало работать для другого). Да, я получу тонны ошибок и буду править возможно неск дней - вот поэтому и надо очень тщательно продумать на что менять.
Нет той самой надежности

Не пресекается старый вызов. И кто ответит за MATERIAL_ID1? Это уже не константа

 

Если, как вы говорите, констант больше нет - надо всё переписывать.

Ну потому что кирпичей нет, а из треугольников домик не построишь.

Понятно что надо, вопрос каким образом. На что менять существующие вызовы?

Я пока вижу такую схемку

1) Переименовать все константы нода "материал", напр X_DIFFUSE_ID вместо DIFFUSE_ID, это вызовет массовые ошибки компилятора, ну и хорошо

2) Править ошибки заменяя

C++ (Qt)
double value = object->GetParamValue(DIFFUSE_ID, currentTime);

На

C++ (Qt)
double value = object->GetMaterialValue(materialIndex, X_DIFFUSE_ID, currentTime);

Ну и по месту откуда-то брать тот materialIndex. В самом объекте мапы

C++ (Qt)
double CObject::GetMaterialValue( uint materialIndex, uint  paramIndex, double currentTime )
{
  Q_ASSERT(materialIndex < m_MaterialMaps.size());
  int ID = m_MaterialMaps[materialIndex].value(paramIndex); // получаем реальное уникальное ID
  Q_ASSRERT(ID);
  return GetParamValue(id, currentTime);
}

При создании/удалении материалов парить m_MaterialMaps их владельцев. Критикуем, пинаем

Да, и неужели нет такого паттерна?  :)

Паттерны это дерево. Вы счас к нему всё и сводите.
А переделка с одного паттерна на другой к паттернам не относится :)

PS у вас нечего критиковать, вы привели мой второй вариант :)

Думал, может человек повзрослел (после длительного отсутствия). Какое там - все та же трещетка, абы чего написать, авось что-то да в масть. Идите отсюда, вертихвост эдакий  :'(

О_о

а если сделать ключи в виде "пути"?

objectPtr->GetParamValue("MATERIAL_ID2/DIFFUSE_ID");

Так это будут те же ключи :D
И проблему igors с тем, что ему переписывать всё придётся не исправят :D

to Igors я тебя тоже, !адекват, люблю :D

Проблема та же - где взять MATERIAL_ID2? (в смысле чему оно соответствует) Только здесь еще отягощенная строками.

Владелец - конечно объект. Юзер указывает что желает еще материал, может еще и еще (хотя и редко). Ну накидать их всех в дерево - дело несложной техники, имеющиеся структуры данных это позволяют. Но как их затем удобно использовать?

А это называется "контрактом" между тем, кто спрашивает (он то знает, что ему надо) и тем, кого спрашивают. Обе стороны должны понимать, что это такое:

const QByteArray MATERIAL_ID2 = "Material2";

(например)

Так и предлагается обсудить условия этого "контракта".
Создаваемый юзером нод "материал" конечно имеет имя, но оно не уникально. Ну и по-прежнему "не въехали" - какое же const если их число переменное? 

Ладно, пожуем. Итак теперь "материалов" может быть не один а много. В любом случае владелец (объект) уже не может запросить просто "параметр материала", он должен указать (конкретизировать) какого именно. Каким образом? (предмет обсуждения). И второе: существующий сынтаксыс не пресекает старого обращения (теперь уже ошибочного). На больших объемах кода это актуально, тоже обсуждаем

- Старый код придется переписать, т.к. он стал неоднозначным. Понимаю, что кода много, но иначе практически никак.
- Убрать все численные константы, т.к. все стало динамическим - в них больше нет смысла.
- Заменить их на строковые ID (QByteArray) - а тут уже полная свобода, материалы и параметры могут называться как душе угодно. Главное, чтобы соблюдался контракт между двумя сторонами (GetParameter("MaterialX/color") - должен быть распознан получателем как "цвет материала X, если такой имеется)

Вопрос "переписывать или нет" вообще не стоит. Нужно чтобы переписанное хорошо "легло" и потом не пришлось месяцами ловить новые баги

"Все" не убрать, материал - лишь один из многих нодов дерева. И откуда упорное стремление к строкам? Здесь не вижу ни одной выгоды от них

Уже говорили что имена есть но не уникальны. И не раз говорили типа "откуда возьмется "MaterialX", т.е. кто и где будет хранить этот (в общем случае) ключ. Топчемся на месте

to Racheengel:
Это же Igors. Ему ответы уже всевозможные дали, но он будет зудеть до последнего, просто выводя из себя людей :D Темы поднимает неплохие, но вот окончательное решение у него одно - "всё уже есть, всё уже сказали, скажите чё-нить новое, чтоб решило проблему сразу".

Однозначность ключей, убирается ограничение на численные константы. Лучше юзать строчку "MaterialX", чем const MATERIAL_X_ID = 12345; - это "12345" еще где-то надо определить, причем следить, чтоб никто больше нигде не переопределил его...


Тут вообще не понял проблемы. "Хранить" значение будет тот, кто предоставляет материалы. А зачем хранить ключи?

По указанию юзера создается новый нод "материал", он добавляется в дерево параметров объекта. Потом возможно еще нод "материал", и еще, а может и наоборот какой-то нод удалят. Сейчас объект просто обращается к ноду по константе, но c переменным числом таких нодов это уже не катит. Псевдокод

C++ (Qt)
double value = GetParamValue(DIFFUSE_ID, currentTime);  // было
 
double value = GetMaterialValue(???, ???, currentTime);  // надо
 

Предложите реализацию GetMaterialValue. Разумеется объект знает к какому конкретно ноду "материал" он сейчас обращается, напр его индекс. Но нужна-то диффуза которая один из чайлд нодов данного материала,  закопана там глубоко

Ну, если совсем грубо:

QMap<QByteArray, QVariant> MaterialParams;
QMap<QByteArray, MaterialParams> Materials;
Materials m_objectMaterials;

QVariant GetMaterialValue(QByteArray materialId, QByteArray paramId)
{
return objectMaterials[materialId][paramId];
}

А чего Вы это замазываете суть (Q)вариантом? Создаваемые материалы должны помещаться в имеющееся дерево, этого никто не отменял.

[off]Эти подачи и возвраты по значению напоминают мне опустившегося человека - не бреется, ходит в рваных вонючих носках, бухает, жрет дуст...[/off]

каноничное завершение темы Igors :D

Типичный, конченный программер  :D

Ладно, вернемся к единственному (пока) кандидату
Ничего "плохого" здесь не вижу, да и реализовать это реально. Но вот с "идейной" точки зрения мне как-то не нравится. Ведь только что объект был "совершенно свободен", все делалось механизмом дерева параметров. Добавлять новые параметры и удалять старые - не вопрос, и это не требует никаких изменений в данных. Нужен параметр для расчетов/использования - дернул его по ключу - и все. А теперь мы начинаем хранить ID ключей - ну как минимум надо обеспечивать их (де)сериализацию, т.е. появились данные (члены класса объект). Хмм...

А вы в любой своей реализации храните свои ключи параметров.
Просто в первом случае они были константами, теперь стали переменными.

PS нашли корову в коровьем стаде, красота :)