суббота, 27 сентября 2014 г.

Построение контекстно-зависимого интерфейса. Part II

В предыдущем примере построения контекстно-зависимого интерфейса, есть существенный минус - прямая зависимость между объектом, инициирующим операцию, и непосредственным исполнителем. В результате потери гибкости, мы не можем независимо изменить взаимодействие между инициатором и исполнителем операции. 

Плодить прямые зависимости между множествами объектов - гарантировать себе и коллегам, в будущем, головную боль, особенно в условиях постоянно развивающегося проекта. Поэтому, если вы не хотите, чтобы у вас отняли клавиатуру, нужно на ранней стадии проекта сказать прямым зависимостям решительное нет и обратиться к классике Design Patterns с существующими практиками. 

Для решения данной задачи давно используется шаблон Command, который отделяет объект инициирующий операцию, от объекта, который знает как её выполнить. Это позволяет добиться высокой гибкости при проектировании пользовательского интерфейса. Пункт меню и кнопка могут быть одновременно ассоциированы с методом презентера, для этого достаточно привязать оба компонента UI к одному и тому же экземпляру Command.
Далее необходимо будет развязать взаимодействие между компонентом UI и объектом Command, для этих целей подойдет шаблон-посредник (Mediator). Посредник знает о компоненте UI и о команде, управляет взаимодействиями между ними, таким как: активация/деактивация компонента UI, вызов метода Execute. 

Ну и чтобы совсем получилось вкусно, хочу чтобы решение работало на платформах WPF и Winforms, иначе для чего было городить весь огород с Separated Presenter. Поскольку WPF поддерживает работу с командами (в виде привязки объекта ICommand), а Windows Forms нет, то далее речь пойдет о практике взаимодействия команд и компонентов UI платформы Windows Forms