Важная экономия кода и здравого смысла, которую вы ищете здесь: декларативный подход и DRY (не повторяйте себя).
[ Пример для следующего: допустим, запрещено включать все 3 флажка A, B и C. ]
Брайан Бэтчелдер дал первый шаг к наведению порядка: напишите единственное правило для правильности каждого флажка:
if(B.isSelected() && C.isSelected()) {
A.forceOff(); // making methods up - disable & unselected
} else {
A.enable();
}
// similar rules for B and C...
// similar code for other relationships...
и переоценивайте это всякий раз, когда что-то меняется. Это лучше, чем рассеяние изменений состояния A во многих местах (когда B изменяется, когда C изменяется).
Но у нас все еще есть дублирование: единое концептуальное правило, для которого комбинации A, B, C являются законными, было разбито на 3 правила для случаев, когда вы можете разрешить бесплатные изменения A, B и C. В идеале вы должны написать только это:
bool validate() {
if(A.isSelected() && B.isSelected() && C.isSelected()) {
return false;
}
// other relationships...
}
и все флажки включения / форсирования выводятся из этого автоматически!
Можете ли вы сделать это из одного правила validate ()? Я думаю, что вы можете! Вы моделируете возможные изменения - validate () вернет true, если A включен? выкл? Если оба варианта возможны, оставьте A включенным; если возможно только одно состояние A, отключите его и установите его значение; если это невозможно - сама ситуация является незаконной. Повторите вышеприведенное моделирование для A = другие флажки ...
Что-то внутри меня жаждет потребовать симуляции всех возможных комбинаций изменений. Подумайте о таких ситуациях, как «A еще не должен отключать B, потому что, хотя в настоящее время он запрещен, при включенном C включение B приведет к выключению C, а с этим B допустимо» ... Проблема в том, что на этом пути лежит полное безумие и непредсказуемый интерфейс поведение. Я считаю, что моделирование изменений только одного виджета за раз относительно текущего состояния - это то, что нужно, но я слишком ленив, чтобы доказать это сейчас. Так что принимайте этот подход с долей скептицизма.
Я также должен сказать, что все это звучит в лучшем случае сбивает с толку пользователя! Несколько случайных идей, которые могут (?) Привести вас к более удобному дизайну GUI (или, по крайней мере, уменьшить боль):
- Используйте структуру GUI, где это возможно!
- Группировка виджетов, зависящих от общего условия.
- Используйте переключатели над флажками и выпадающими выборками, где это возможно.
Радиокнопки можно отключить индивидуально, что улучшает обратную связь.
- Используйте переключатели, чтобы сгладить комбинации: вместо флажков "A" и "B", которые не могут быть включены одновременно, предложите переключатели "A" / "B" / "none".
- Список ограничений совместимости в графическом интерфейсе / подсказках!
- Автоматически генерировать всплывающие подсказки для отключенных виджетов, объясняя, какое правило заставило их?
Это на самом деле легко сделать.
- Рассмотрите возможность разрешения противоречий, но перечислите нарушенные правила в области состояния, требуя от пользователя разрешения, прежде чем он сможет нажать OK.
- Реализовать отмену (& redo?), Чтобы отключение виджетов не было разрушительным?
- Помните назначенное пользователем состояние флажков при их отключении, восстанавливать, когда они становятся включенными? [Но остерегайтесь изменения вещей без замечаний пользователя!]