Поведенческие шаблоны проектирования

Посредник

Если стоит необходимость проектирования и реализации системы или ее модуля с использованием существующих компонентов, на уже реализованные связи между этими компонентами можно характеризовать феноменом "Спагетти-кода", стоит задуматься о применении шаблона проектирования "Посредник".

"Спагетти-код"– низкоструктурированная, запутанная и трудная для понимания программа. "Спагетти-код" назван так, потому что ход выполнения программы похож на миску спагетти–извилистый и запутанный.

Шаблон "Посредник" применяется в том случае, когда необходимо обеспечить взаимодействие множества объектов, сформировав при этом слабую связанность и избавив объекты от необходимости явно ссылаться друг на друга.

"Посредник" используется в системах, где взаимодействие между компонентами может быть весьма сложным, но хорошо определенным. Особенно актуальным является внедрение этого паттерна, если есть предпосылки к тому, что связи между модулями будут постоянно расти и усложняться. Шаблон "Посредник" можно сравнить с уже рассмотренным ранее архитектурным шаблоном "Диспетчер". Они выполняют схожие функции, но обладают разными обязанностями.

Для реализации шаблона "Посредник" потребуется:

1. Создать новый объект (посредник), инкапсулирующий способ взаимодействия множества существующих объектов (коллеги).
2. Новый объект должен определять интерфейс для обмена информацией с существующими объектами.
3. Конкретный посредник должен координировать действия объектов коллеги.
4. Каждому классу коллег необходимо знать о своем посреднике.
5. Коллеги обмениваются информацией только с посредником.
6. Посредник реализует кооперативное поведение, пересылая каждый запрос одному или нескольким коллегам, в зависимости от его назначения.

Шаблон "Посредник" определяет объект, управляющий набором взаимодействующих объектов. Слабая связанность достигается благодаря тому, что вместо непосредственного взаимодействия друг с другом коллеги общаются через объект-посредник.

Для того чтобы внедрение шаблона "Посредник" в программу было выполнено наиболее эффективным образом, необходимо предварительно:

• определить совокупность взаимодействующих объектов, связанность между которыми нужно уменьшить;
• инкапсулировать все взаимодействия в абстракцию нового класса;
• создать экземпляр этого нового класса;
• найти"правильный" баланс между слабой связанностью и распределением ответственности.

Применение шаблона "Посредник" позволяет:

• снизить связанность между коллегами;
• централизовать управление системой: этот шаблон заменяет способ взаимодействия " все со всеми " на взаимодействие "один со всеми";
• упростить внедрение новой функциональности благодаря слабой связанности кода.

Недостатки же его использования следующие:

1. Модули больше не могут взаимодействовать напрямую.
2. Использование медиатора приводит к предсказуемому падению производительности–из-за слабой связанности становится достаточно трудно определить реакцию системы, отталкиваясь только от событий, происходящих в ней.

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

Состояние

В ситуациях, когда требуется варьировать поведение объекта в зависимости от его внутреннего состояния, используют шаблон проектирования cодноименным названием–"Состояние".

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

Структура этого паттерна определяется следующим образом:

1. Определенный класс (1)должен содержать определение внешнего интерфейса и хранить внутри себя ссылку на текущее состояние объекта.
2. Интерфейс абстрактного базового класса (2)должен повторять интерфейс класса (1) за исключением одного дополнительного параметра – указателя на экземпляр (1).
3. Производные от (2) класса определяют поведение, специфичное для конкретного состояния.
4. Класс "Обертка"(1) делегирует все полученные запросы объекту "Текущее состояние", который может использовать полученный дополнительный параметр для доступа к экземпляру класса (1).

Реализацию паттерна "Состояние" можно организовать следующим способом:

• Класс "Контекст" делегирует зависящие от состояния запросы текущему объекту "Конкретное состояние" и определяет интерфейс, представляющий интерес для клиентов. Таким образом, необходимо хранить экземпляр подкласса "Конкретное состояние", которым определяется текущее состояние.
• "Конкретное состояние" реализует поведение, ассоциированное с неким состоянием объекта "Контекст".
• "Состояние" определяет интерфейс для инкапсуляции поведения, ассоциированного с конкретным экземпляром "Контекст".

Использование шаблона "Состояние" локализует зависящее от состояния поведение и делит его на части, соответствующие состояниям, переходы между состояниями становятся явными, а процесс работы с объектом – более прозрачным и понятным.

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

увеличить изображение
Рис. 6.2.8. Шаблон "Состояние"