CC BY
61
А.Н. Моисеев
КОНТРОЛЛЕР ИНТЕРФЕЙСА ПОЛЬЗОВАТЕЛЯ С ПОВЫШЕННОЙ СТЕПЕНЬЮ
ПОВТОРНОЙ ИСПОЛЬЗУЕМОСТИ
Представлено решение задачи проектирования слоя интерфейса пользователя с повышенной степенью повторной используемости контроллера. Показано, что применение шаблона проектирования 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 г.
