Russian Qt Forum

Добрый всем день :)

Обращаюсь с вопросом по архитектуре - очень хотелось бы услышать Ваше мнение :)
В общем, дело такое - есть девайс, имеющий N параметров. Каждый параметр - это некая величина, задаваемая во внутренних единицах, и имеющая определенные интервалы значений (например 100...1023 и т.д.).
Необходимо предоставить пользователю гуй с возможностью редактирования данных параметров. Однако на гуе они должны быть представлены не в единицах, понимаемых девайсом, а, скажем, в процентах от 0 до 100%. Собственно, технически реализовать все это не проблема, вопрос больше в том, какой подход лучше использовать.

Сейчас имеется 2 варианта решения.
1 - вместе со значением параметра в гуй передаются его границы (constrains). Гуй отображает, скажем, QSlider с учетом данных ограничений, выводя пользователю пересчитанное в процентах значение параметра (т.е. например если мы имеем границы -50..+50 и значение +25, то на гуе будет отображено 75% и т.д.). При передаче измененного пользователем значения в класс девайса, гуй просто отдаст физическое значение величины, которое может быть записно в железо "как есть".

2 - гуй ничего не знает о границах параметров. Его интерфейс принимает значения в интервале 0...1, что соответстувет 0...100%, и отдает в таком же виде. Пересчетом занимается класс девайса.

Лично я больше за 1 вариант, т.к. он мне кажется более простым и универсальным - класс девайса ничего не знает о том, какие значения видит пользователь. Гуй, в свою очередь, получает реальные значения и может делать с ними, что угодно (показать как есть, в процентах, или еще как-то). К тому же класс девайса освобождается от пересчета значений, а значит, количества ошибок :)

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

Кто что думает, колееги? :)

Счастливый человек - видимо все другие проблемы уже решены и остаётся заниматься только терзаться такими муками выбора :).
С моей точки зрения оба варианта имеют право на жизнь. В любом случае это кто-то должен переводить значения в проценты и обратно: либо это будет gui часть, либо девайс. Мне больше нравится вариант 2 (почти цитата): "Лично я больше за 2 вариант, т.к. он мне кажется более простым и универсальным - gui ничего не знает о том, какие там единицы измерения используются внутри девайса и как их преобразовывать в проценты."

Вариант №2.

первый вариант более гибкий в том плане, что вы не затрагивая класса устройства сможете изменить способ представления данных в GUI, отображая как проценты, так и физические величины. если исходя из специфики задачи этого совершенно точно не понадобится - используйте второй вариант.

Странник, переключение между представлением параметров, скорее всего, понадобится - нужен будет вид "для пользователя" и "для инженера".

В варианте 2 я вижу 2 недостатка - во первых, если параметров много и у каждого свои границы, то придется делать N разных пересчетов в классе девайса, что может привести к багам (вместо того, чтоб 1 раз сделать это в гуе). Во вторых, добавляется еще один "уровень" - пересчет из внутренних величин в альфу (0..1), потом в гуе пересчет альфы в проценты.

В варианте 1 недостаток - напряжненько имплементировать нелинейные параметры.  Ну и передача констрейнов в гуй - тоже доп. работа. Хотя имхо он более гибок в плане, "показывай как хочешь".

xokc, дело не в том, что я "Счастливый человек" :) Просто изначально нужно сделать универсальную архитектуру, чтоб потом 100 раз не патчить :)

Serr500, а можешь обосновать, почему 2?

Имхо, это достаточно серьезно, в том смысле, что казалось бы мелочь, но если встречается то тут, то там, и в одном месте вы сделали так, а в тругом несколько иначе, то такой код шумит, и это плохо!

Есть мнение, что если некий функционал полностью выражается через паблик интерфейс класса, то его не нужно реализовывать в этом классе (например, см. как Герб Саттер ощипал std::string в пользу свободных фукций).

Поэтому, если выделить преобразование величин в отдельный класс, то получится более сфокусированная архитектура (см. Low Coupling/High Cohesion): например, клиенты девайса, которым не нужно это преобразование, не получают его в нагрузку.

Для неоткровенных ортодоксов вариант 2 вполне приемлем на практике. Вариант 1 содержит бизнес-логику в гуе.

Если есть такое требование, то всё, похоже, сводится к классическому MVC - одна модель и несколько вью для неё. Т.е. появляется вариант № 3, как уже и сказал Akon: выделить преобразование величин в отдельный класс.

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

Спасибо за участие, коллеги! У нас сейчас ситуация 50 на 50, часть народа за 1, часть за 2 вариант :) Пока имплементировали 2, но как то кривовато... "будем думать"...

Как же он его ощипал? Если нетрудно киньте ссылку. Спасибо

В какой-то мере содержит, но отображать "только проценты" и/или значения 0..1 вряд ли устроит. Поэтому я за вариант 1. По ходу дела возникают такие коллизии

- есть параметр с типичным диапазоном использования напр 1..10. Однако редко, но все же бывает что потребовалось значение напр 20, это не запрещено. Если абсолютные значения предъявлены - проблемы нет

- к сожалению, при большом числе параметров места на слайдеры часто не хватает

С моей точки зрения он более правильный. Этот подход разделяет вид и реализацию. В виде (view) пользователь выставляет проценты, поэтому пусть вид и оперирует тем, что меняет пользователь. А внутренняя реализация класса уже оперирует своими абсолютными значениями. Это "развязывает" вид и реализацию, они оказываются независимыми. Вид не имеет понятия о реализации, что позволяет ему не меняться при её смене. Например, если вместо диапазона -50...+50 вдруг придётся использовать диапазон -100500...+100500, придётся менять не только реализацию, но и вид. Во втором случае вид вообще не будет затронут. А функции-преобразователи процентов в абсолютные значения будут очень простыми и быстро выполняющимися. Фактически, класс при таком подходе предоставляет некоторый интерфейс, независимый от своей внутренней реализации.

Serr500, основная идея варианта 1 в том, что гую передается И параметр, И его диапазон. Т.е. гуй в любом случае неизменен - он знает, что пришло значение, например, 15, и интервал -5..35. Тогда он просто отображает процентное значение как 50%. Если интервал изменится - гуй прочитает его, опять же, из класса девайса, но код его в любом случае не будет меняться.

Igors, да, скорее всего, надо будет отображать И проценты, И внутреннюю величину (для инженеров).

Ой да как мы умеем "обосновать", "подвести базу" и.т.п. :) Понятно что "2" для программиста заметно легче и обобщается гораздо лучше. Вот только у пользователя свои запросы с которыми надо (разумно) считаться.

Ну проценты показывать необов'язково - по позиции слайдера понятно. Но отделаться "диапазоном" вряд ли удастся, там налипает гораздо больше: тип данных (хотя бы int/float), дефаулт значение, разрешен ли выход за диапазон и.т.п. В общем, забот хватит если делать для людей, а не играться в красивые абстрактные конструкции  :)

Это в его книге "Новые сложные задачи ..." (называется как-то так). Если не ошибаюсь, раздел "Ослабленная монолитность".

А преобразование это не бизнес-логика? Ок, пусть параллельно с гуем будет консольный интерфейс и в нем будет интерактивный запрос "Введите значение параметра ХХХ в %:". А теперь смотрим стереотипные фрагменты кода в гуе и в консоли... (это будет преобразование)

Нет, т.к. это преобразование необходимо только для визуализации. Алгоритмика его не требует.

В случае нескольких разнотипных гуев, все равно будет необходим пересчет альфы в проценты и назад. Тут надо его либо выносить отдельно, ваша правда :), либо, как вариант, каждому такому гую отнаследоваться от класса преобразователя.

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

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