Банальная задачка UI

[Igors]

Добрый день

Есть окно в которое заряжается список объектов. В том же окне есть обильный (десятка 2 и еще растет) список "модифайеров", т.е. операций. Юзер выбирает нужный modifier из попапки, напр Fill, устанавливается панелька с его опциями. Юзверь устанавливает их и давит бубочку Apply, поля объектов заполняются каким-то значением. Может все кадры, может некоторые.

Ну не то чтобы я совсем уж не знаю как делать, но все-таки интересно как грамотно. Напр первое впечатление типа: ага, модифайеров реально много, ну значит базовый класс c virtual Apply() и наследоваться, наследоваться... Но если поразмыслить - так ли уж это хорошо? Никаких общностей у тех модифайеров не видать, "зато" все они совершенно беспомощны без диалога (фактически "контекста") который диктует как и к чему действие применяется. Можно  броситься в др крайность - запихнуть все в сам диалог, данные модифайеров - пассивные структуры. Ну будет развесистый свитч, ну и ладно.

В общем, а ну-ка набросайте мне архитектуру И не надо стонать, что, мол, "зависит от задачи" 

Спасибо

[qate]

имеется ввиду чтото похожее на фильтры (плагины) гимп/фотошоп ?
т.е. для них общим является только изображение, и связи между ними нет

[Igors]

Пример. Есть объект (напр сфера) анимированный по кадрам. Юзверь выбирает его, указывает что менять (напр позиция сферы X) и на каком диапазоне (напр кадры 10-20). Эти данные добавляются в упомянутый диалог где могут выполняться разнообразные действия (ну хотя бы прописать нулями)

[ViTech]

Однозначно всё нужно запихнуть в диалог. Зачем дублировать код и распылять его по куче классов. А в диалоге модификаторы сразу на нужном месте.

Тех же, кто посоветует паттерн Visitor, или ещё какую заумную штуку, следует заклеймить в поклонении Букварю и предать анафеме. Ибо негоже пятнать чистую иерархию классов всякими еретичными методами.

Примечание: Variant еретичным не считается.

[Racheengel]

Не совсем понятно...
Область применения модифаеров - ТОЛЬКО диалог?
Те. они применяются не к "модели данных", а только к объектам диалога?

[Igors]

Область применения модифаеров - ТОЛЬКО диалог?

Пока (и в обозримом будущем) да. История. Была (и есть) большая таблица (типа спрыдшыт) в ней юзер чего-то выбирал и сразу вызывал из меню модифайер, его опции появлялись в модальном диалоге. Это однако имело дефект - неясно что и как должно модифицироваться для разнородных выборок. Также есть др большое окно где ряд параметров представлен в виде графиков. Там тоже насовали кучу менюх что по существу тоже "зовут модифайеры". Ну и наконец неплохо иметь возможность менять параметры "без всякого окна" просто выбрав их из списка. Поэтому решили разгрузить окна и объединить модифайеры в одном большом новом диалоге.

Те. они применяются не к "модели данных", а только к объектам диалога?

Объекты диалога - всего лишь ссылки на модели данных.

Однозначно всё нужно запихнуть в диалог. Зачем дублировать код и распылять его по куче классов. А в диалоге модификаторы сразу на нужном месте.

И не только модифайеры, но и весь "контекст". Правда смешивать UI с "бизнес-логикой" (идиотский термин) не есть хорошо, но... то ж в теории, а у нас конкретный случай (и.т.п.)

Тех же, кто посоветует паттерн Visitor, или ещё какую заумную штуку, следует заклеймить в поклонении Букварю и предать анафеме. Ибо негоже пятнать чистую иерархию классов всякими еретичными методами.

Примечание: Variant еретичным не считается.

Не вижу причем тут Visitor, Variant и вообще раздраженная ирония Будут ли модифайеры расписаны свитчом или виртуалами или темплейтами - совсем не тот вопрос что я хотел обсудить. Дело в другом. Вот я не раз упоминал о "контексте". Пример

Код

C++ (Qt)
virtual bool AbstractModifier::Modify( QVariant & target );

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