Подписчик
Название. Подписчик (subscriber) или подписчик-издатель (publisher-subscriber). Известен также под названиями "наблюдатель" (observer), "слушатель" (listener) или "подчиненные" (dependents).
Назначение. Реализация системы, в которой нужно поддерживать согласованными состояния большого числа объектов. Чаще всего при этом достаточно много компонентов зависит от небольшого набора данных. Можно было бы связать их явно, введя обращения ко всем компонентам, которые должны знать об изменениях, при каждом внесении изменений, но полученная система станет очень жесткой. Добавление нового компонента потребует сделать изменения во всех местах, от которых он зависит. Предлагаемое в рамках данного образца решение основано на гибкой связи между субъектом (от которого зависят другие компоненты) и этими зависимыми компонентами, называемыми подписчиками. Здесь нужно принимать во внимание следующие факторы:
Действующие силы.
- Об изменениях в состоянии некоторого компонента должны узнавать один или несколько других компонентов.
- Количество и конкретный вид компонентов, которые должны оповещаться об этих изменениях, заранее не известны или могут быть изменены во время работы приложения.
- Проведение зависимыми компонентами время от времени явных запросов о произошедших изменениях неэффективно.
- Источник информации (субъект или издатель) не должен быть тесно связан со своими подписчиками или зависим от них.
Решение. Компонент, от которого зависят другие, берет на себя функции издателя. Он предоставляет интерфейс для регистрации компонентов-подписчиков, заинтересованных в информации о его изменениях, и хранит множество зарегистрированных подписчиков. При изменениях он оповещает их с помощью вызова предназначенного для этого метода update().
увеличить изображение
Рис. 8.4. Структура классов подписчиков и издателя
Структура. Основными компонентами являются издатель (или субъект) и подписчики (или наблюдатели). Подписчики реализуют общий интерфейс, у которого имеется метод update() для оповещения подписчика о том, что в состоянии издателя произошли изменения.
Издатель хранит множество подписчиков, позволяет регистрировать или удалять их из этого набора. При возникновении изменений он оповещает все элементы этого множества при помощи метода update().
Динамика. Можно использовать два вида обновления подписчиков: издатель сам может сообщать им о том, какие именно изменения произошли (схема проталкивания, push model), или после получения уведомления подписчик сам обращается к издателю, чтобы узнать, что именно изменилось (схема вытягивания, pull model). Вторая схема значительно более гибкая, она позволяет подписчикам получать только необходимую им информацию, в то время как согласно первой схеме каждый подписчик получает всю информацию о произошедших изменениях.
увеличить изображение
Рис. 8.5. Сценарий оповещения об изменениях по схеме вытягивания
Реализация. Основные шаги реализации следующие:
- Определить протокол обновления — будет ли использоваться простой метод update() или в качестве его параметров нужно будет передавать изменившийся объект-издатель и данные произошедшего изменения.
- Определить схему обновления одного подписчика: на основе проталкивания или на основе вытягивания информации.
- Определить отображение издателей на подписчиков. Если издателей много, а подписчиков мало, то хранение множеств подписчиков для каждого издателя может быть неэффективным — для экономии памяти за счет времени поиска подписчиков можно использовать отдельную таблицу, отображающую издателей на подписчиков.
- Обеспечить гарантии целостности состояния издателя перед оповещением подписчиков.
- Обеспечить гарантии аккуратного удаления объекта-подписчика из системы — нужно, чтобы он был удален из всех списков оповещений.
- Если семантика обновлений сложна, например, если подписчик зависит от нескольких издателей, которые могут изменяться в рамках одной операции, то, возможно, потребуется выделить такие сложные связи в отдельный компонент, называемый менеджером изменений (change manager). Такой компонент должен сам хранить отображение между издателями и подписчиками, определять стратегию проведения обновления и обновлять всех зависимых подписчиков по запросу от издателя.
В качестве стратегии обновления может выступать механизм, гарантирующий подписчику получение только одного уведомления, если изменяются несколько издателей, от которых он зависит.
Следствия применения образца.
Достоинства:
- Слабая связанность между издателем и подписчиками — издатель знает только, что у него есть несколько подписчиков с одинаковым интерфейсом.
- Удобным образом, не зависящим от числа участников, поддерживаются широковещательные оповещения.
Недостатки:
- Низкая производительность в случае большого количества подписчиков — даже небольшое изменение требует оповестить их всех, и каждый из них будет пытаться провести обновление своего состояния.
- Неэффективное использование информации из-за необходимости оповещать всех подписчиков, даже тех, для которых выполненные изменения несущественны. Кроме того, подписчик может зависеть от нескольких издателей и не знать, какой именно издатель оповещает его об изменении. Чтобы исправить эту ситуацию, необходимо внесение изменений в протокол оповещения — предоставление дополнительной информации, как об изменившемся издателе, так и о виде изменения.
Примеры. Один из примеров мы уже видели — в рамках более широкого стиля "данные–представление–обработка" представления и обработчики являются подписчиками по отношению к модели-издателю.
Вариант этого образца с введением менеджеров изменений описан под названием "канал событий" (Event Channel) в спецификации службы оповещения о событиях в стандарте CORBA [2].
