Refactor to Design Pattern: отображение / скрытие различных комбинаций элементов управления в зависимости от состояния

Question

Предположим, у вас есть элементы управления A, B, C, D и E со свойством Visibility. У вас также есть состояния 1,2,3,4,5 и 6, в которых будут отображаться различные комбинации ваших элементов управления.

В настоящее время это обрабатывается операторами switch для каждого состояния: т.е.

Select Case PageState
    case "1"
      a.visible = false
      b.visible = true
      c.visible = false 
      d.visible = true
      e.visible = false
   case "2"
      a.visible = true
      b.visible = true
      c.visible = false 
      d.visible = true
      e.visible = false
  case ... 
 End Select

Как вы можете себе представить, это становится болью, так как каждому состоянию нужен оператор show / hide для каждого элемента управления. Как я могу реорганизовать это так, чтобы добавление элементов управления и / или состояний стало тривиальным?

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

Редактировать Я был намеренно расплывчат в своем вопросе на случай, если это будет иметь другие последствия. В моем текущем случае "контрольными элементами" являются панели ASP. Это что-то меняет?

Answer 1

Использовать шаблон состояния

Answer 2

Используйте шаблон состояния. Пусть каждое состояние работает на вашей странице (абстрагировано как интерфейс):

public interface IControlSituationPage // your page implements this
{
    void SetAvisibility(bool visibility);
    void SetBVisibility(bool visibility);
    ...
}

....

public interface PageState // each state implements this
{
    void ApplyState(IControlSituationPage page);
}

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

// ... somewhere..
_state.ApplyState(this);

Конечно, вместо фактического использования более надежного шаблона представления, такого как MVC или MVP.

Answer 3

[Примечание: я Java-парень, поэтому моя реализация ниже на Java - она ​​должна быть очень похожа на C # или любой другой язык, который вы хотите использовать]

Роб указывает на проблему с вышеприведенным решением - оно действительно не поддается обслуживанию.

Это также невероятно многословно (обычно шаблон состояния GoF ...).

Иногда шаблон State не совсем то, что вы должны использовать.

Как насчет вывернуть проблему наизнанку и позволить данным управлять ею?

Посмотрите на это как «для каких состояний должен отображаться X?»

Попробуйте что-то вроде следующего:

1. создать перечисление, представляющее ваши состояния
2. создать EnumSet для каждого элемента управления (они очень эффективны)
3. в каждом EnumSet, добавьте состояния, для которых этот элемент управления должен быть видимым
4. при изменении состояния проверьте видимость каждого элемента управления

Схематичная реализация (не скомпилирована / не протестирована)

public enum MyStates {State1, State2, State3...}

public class VisibilityManager {
    private Map<Component, Set<MyStates>> managedComponents =
        new HashMap<Component, Set<MyStates>>();
    private Component component;
    public void setVisibility(Component component, MyStates... states) {
        Set<MyStates> visibleStates = EnumSet.of(states);
        managedComponents.put(component, states);
    }
    public void update(MyStates currentState) {
        for (Map.Entry<Component, Set<MyStates>> e : managedComponents.entrySet())
            e.getKey().setVisible(e.getValue().contains(currentState));
    }
}

// then in your GUI setup

VisibilityManager v = new VisibilityManager();
v.setVisibility(comp1, MyStates.State1, MyStates.State2);
v.setVisibility(comp1, MyStates.State3);
v.setVisibility(comp1, MyStates.State1, MyStates.State3, MyStates.State5);
...

// and when you change the state
v.update(newState);

Надеюсь, это поможет!

Answer 4

Скотт понял: для таких тривиальных случаев (когда вам нужен только контроль над видимостью) имеет смысл придерживаться обратной логики. Шаблон состояний становится чрезвычайно полезным, если вам нужно выполнить переходы состояний и сделать свой интерфейс абстрагированным от бизнес-логики.