Контроллер интерфейса пользователя с повышенной степенью повторной используемости

А.Н. Моисеев

КОНТРОЛЛЕР ИНТЕРФЕЙСА ПОЛЬЗОВАТЕЛЯ С ПОВЫШЕННОЙ СТЕПЕНЬЮ

ПОВТОРНОЙ ИСПОЛЬЗУЕМОСТИ

Представлено решение задачи проектирования слоя интерфейса пользователя с повышенной степенью повторной используемости контроллера. Показано, что применение шаблона проектирования Mediator (Посредник), с одной стороны, позволяет уменьшить связность элементов интерфейса, а использование в сочетании с ним паттерна Observer (Наблюдатель) совместно с архитектурным решением Separated Interface (Отделенный Интерфейс), с другой стороны, позволяет изолировать эти элементы и сам контроллер слоя от конкретики реализации.

Концепция слоев (Layers) [1] является одним из основополагающих принципов объектно-ориентированной разработки программных систем. Данный подход позволяет изолировать подсистемы, повышая степень повторной используемости кода и уменьшая связанность (Coupling) [2] объектов системы. Изоляция слоев обычно реализуется с использованием паттернов Facade (Фасад) [3] и Controller (Контроллер) [2].

Представление HI - Controller

nL

“L PD - Controller

Домен

1 DM - Controller

Данные

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

Рис. 2. Типичная структура связей между классами слоя представления

Решение, которое может помочь в данной ситуации, заключается в применении паттерна Mediator (Посредник) [3] для реализации контроллера интерфейса пользователя (рис. 3). Этот паттерн предполагает полную изоляцию классов-коллег (в данном случае - элементов интерфейса) друг от друга, а их взаимодействие осуществляется через специально введенный объект-посредник, который и будет являться котроллером интерфейса пользователя.

Рис. 1. Иерархия слоев системы и место контроллеров во взаимодействии подсистем

На рис. 1 показано взаимодействие объектов различных слоев и место контроллеров в них (HI - Human Interface - интерфейс с пользователем, представление; PD - Problem Domain - предметная область, домен; DM - Data Management - управление данными, данные). Следует обратить внимание на то, что для построения класса HI-Controller, в отличие от других контроллеров, не используется паттерн Facade, так как элементы интерфейса пользователя находятся в самом верхнем слое и кроме внутренних объектов этого слоя к ним не могут обращаться никакие другие объекты.

Рис. 3. Применение паттерна Посредник в слое представления

Данный подход позволяет снизить связность классов слоя представления, обеспечивая тем самым пол-

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

Единственным недостатком данного подхода является строгая привязка интерфейсных объектов к классу контроллера и самого контроллера - к классам интерфейсных элементов. Данный недостаток может быть устранен путем выделения абстракций контроллера-посредника и интерфейсного элемента-коллеги и применения паттерна Observer (Наблюдатель) [3] для реализации взаимодействия конкретных классов (рис. 4). Кроме того, такой подход позволит реализовать операции управления подписчиками (в данном случае - объектами интерфейса) в родительском классе, увеличив тем самым повторную используемость не только самого класса контроллера и отдельных интерфейсных объектов, но и всей архитектуры слоя представления. При реализации данного подхода на практике мы неизбежно столкнемся с необходимостью применения архитектурного решения Separated Interface (Отделенный Интерфейс) [4] как для класса контроллера, так и для классов представлений. Данное архитектурное решение позволяет устанавливать связи между классами на уровне их абстракций, что гармонично дополнит базовую архитектуру слоя в целом (на рис. 4 разделение на пакеты показано пунктирными линиями).

Обязанности классов, представленных на диаграмме рис. 4, достаточно подробно описаны в [3].

Рис. 4. Применение паттерна Observer и архитектурного решения Separated Interface для изоляции от конкретики реализации

Итак, в отличие от контроллеров других слоев системы, которые реализуются с использованием паттерна Facade, контроллер интерфейса пользователя должен быть реализован по шаблону Mediator с применением паттерна Observer и архитектурного решения Separated Interface. Первое уменьшает связность интерфейсных элементов между собой, а второе и третье - позволяют изолировать конкретику реализации элементов и самого контроллера, сделав архитектуру слоя представления более устойчивой и повысив ее повторную используемость.

1. Buschmann F., Meunier R., Rohnert H., Sommerlad P. and Stal. Pattern-Oriented Software Architecture: A System of Patterns - West Sussex. Eng-

land: Wiley, 1996.

2. Ларман К. Применение UML и шаблонов проектирования. 2-е изд. М.: Изд. дом «Вильямс», 2002.

3. Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. Приемы объектно-ориентированного проектирования. Паттерны проектирования. СПб.:

Питер, 2001.

4. Фаулер М. Архитектура корпоративных программных приложений. М.: Изд. Дом «Вильямс», 2004.

Статья представлена кафедрой прикладной информатики факультета информатики Томского государственного университета, поступила в научную редакцию «Информатика» 6 июня 2006 г.