В.В. Кулямин - Технологии программирования. Компонентный подход (1134162), страница 34
Текст из файла (страница 34)
Подписчик (subscriber) или подписчик-издатель (publisher-subscriber). Известентакже под названиями «наблюдатель» (observer), «слушатель» (listener) или «подчиненные»(dependents).Назначение. Реализация системы, в которой нужно поддерживать согласованнымисостояния большого числа объектов.
Чаще всего при этом достаточно много компонентовзависит от небольшого набора данных. Можно было бы связать их явно, введя обращенияко всем компонентам, которые должны знать об изменениях, при каждом внесенииизменений, но полученная система станет очень жесткой. Добавление нового компонентапотребует сделать изменения во всех местах, от которых он зависит. Предлагаемое врамках данного образца решение основано на гибкой связи между субъектом (от которогозависят другие компоненты) и этими зависимыми компонентами, называемымиподписчиками. Здесь нужно принимать во внимание следующие факторы.Действующие силы.• Об изменениях в состоянии некоторого компонента должны узнавать один илинесколько других компонентов.• Количество и конкретный вид компонентов, которые должны оповещаться об этихизменениях, заранее не известны или могут быть изменены во время работыприложения.• Проведение зависимыми компонентами время от времени явных запросов опроизошедших изменениях неэффективно.• Источник информации (субъект или издатель) не должен быть тесно связан сосвоими подписчиками или зависим от них.Решение.
Компонент, от которого зависят другие, берет на себя функции издателя. Онпредоставляет интерфейс для регистрации компонентов-подписчиков, заинтересованных винформации о его изменениях, и хранит множество зарегистрированных подписчиков. Приизменениях он оповещает их с помощью вызова предназначенного для этого методаupdate().Publisherobservers0..*attach (Subscriber)detach (Subscriber)notify ()getState ()publisherSubscriberupdate ()forall o in observers{ o.update(); }ConcreteSubscriberupdate ()Рисунок 54. Структура классов подписчиков и издателя.Структура. Основными компонентами являются издатель (или субъект) и подписчики(или наблюдатели). Подписчики реализуют общий интерфейс, у которого имеется метод111update() для оповещения подписчика о том, что в состоянии издателя произошлиизменения. Издатель хранит множество подписчиков, позволяет регистрировать илиудалять их из этого набора. При возникновении изменений он оповещает все элементыэтого множества при помощи метода update().Динамика.
Можно использовать два вида обновления подписчиков: издатель сам можетсообщать им о том, какие именно изменения произошли (схема проталкивания, pushmodel), или после получения уведомления подписчик сам обращается к издателю, чтобыузнать, что именно изменилось (схема вытягивания, pull model).
Вторая схема значительноболее гибкая, она позволяет подписчикам получать только необходимую им информацию,в то время как согласно первой схеме каждый подписчик получает всю информацию опроизошедших изменениях.PubllisherchangeSubscriber 1Subscriber 2notifyupdateget stateupdateget stateРисунок 55. Сценарий оповещения об изменениях по схеме вытягивания.Реализация. Основные шаги реализации следующие.• Определить протокол обновления — будет ли использоваться простой методupdate() или в качестве его параметров нужно будет передавать изменившийсяобъект-издатель и данные произошедшего изменения.• Определить схему обновления одного подписчика: на основе проталкивания или наоснове вытягивания информации.• Определить отображение издателей на подписчиков.
Если издателей много, аподписчиков мало, то хранение множеств подписчиков для каждого издателя можетбыть неэффективным — для экономии памяти за счет времени поиска подписчиковможно использовать отдельную таблицу, отображающую издателей на подписчиков.• Обеспечить гарантии целостности состояния издателя перед оповещениемподписчиков.• Обеспечить гарантии аккуратного удаления объекта-подписчика из системы —нужно, чтобы он был удален из всех списков оповещений.• Если семантика обновлений сложна, например, если подписчик зависит отнескольких издателей, которые могут изменяться в рамках одной операции, то,возможно, потребуется выделить такие сложные связи в отдельный компонент,называемый менеджером изменений (change manager).
Такой компонент должен самхранить отображение между издателями и подписчиками, определять стратегиюпроведения обновления и обновлять всех зависимых подписчиков по запросу отиздателя. В качестве стратегии обновления может выступать механизм,гарантирующий подписчику получение только одного уведомления, еслиизменяются несколько издателей, от которых он зависит.112Следствия применения образца.Достоинства• Слабая связанность между издателем и подписчиками — издатель знает только, чтоу него есть несколько подписчиков с одинаковым интерфейсом.• Удобным образом, не зависящим от числа участников, поддерживаютсяшироковещательные оповещения.Недостатки• Низкая производительность в случае большого количества подписчиков — даженебольшое изменение требует оповестить их всех, и каждый из них будет пытатьсяпровести обновление своего состояния.• Неэффективное использование информации из-за необходимости оповещать всехподписчиков, даже тех, для которых выполненные изменения несущественны.Кроме того, подписчик может зависеть от нескольких издателей и не знать, какойименно издатель оповещает его об изменении.
Чтобы исправить эту ситуацию,необходимо внесение изменений в протокол оповещения — предоставлениедополнительной информации, как об изменившемся издателе, так и о видеизменения.Примеры. Один из примеров мы уже видели — в рамках более широкого стиля «данныепредставление-обработка» представления и обработчики являются подписчиками поотношению к модели-издателю.Вариант этого образца с введением менеджеров изменений описан под названием «каналсобытий» (Event Channel) в спецификации службы оповещения о событиях в стандартеCORBA [2].ИдиомыИдиома представляет собой типовое решение, определяющее специфическую структуризациюэлементов кода на некотором языке программирования. Чаще всего это некоторый «трюк», спомощью которого можно придать программе на данном языке нужные свойства.
При этомидиома может оказаться специфичной для языка и не иметь аналога в других языках. Кроме того,очень часто удачные идиомы при развитии языков программирования превращаются в новыесинтаксические конструкции, делающие такую идиому ненужной.Далее мы увидим примеры таких идиом в виде соглашений о построении кода компонентовJavaBeans, превратившихся в C# в элементы языка.В этой лекции мы рассмотрим в качестве примера идиому «шаблонный метод» [3].Шаблонный методНазвание. Шаблонный метод (template method).Назначение.
Фиксация общей схемы некоторого алгоритма, имеющего много вариантов, спредоставлением возможности реализовать эти варианты за счет переопределенияотдельных его шагов, без изменения схемы в целом. При использовании этой идиомынужно принимать во внимание следующие факторы.Действующие силы.• Инвариантные части алгоритма нужно записать один раз и переиспользовать,изменяя только варьирующиеся шаги и элементы.• Иногда такие инвариантные части еще нужно выделить, чтобы сделать болеепонятным и более удобным для сопровождения код нескольких классов,реализующих близкие по назначению методы.• Многие алгоритмы при их практическом использовании могут зависеть от большогочисла факторов, изменяющихся гораздо чаще, чем общая схема такого алгоритма(вспомните принцип разделения политик и алгоритмов).113Решение.
Общая схема алгоритма, которую нужно зафиксировать, помещается вабстрактный класс в виде метода, код которого реализует эту схему. В тех местах, гденеобходимо использовать какой-то варьирующийся элемент алгоритма, этот методобращается к другому методу данного класса, который можно переопределить в классахпотомках.Структура. Метод, реализующий основную схему алгоритма, называется шаблоннымметодом. Он пишется один раз в абстрактном базовом классе и не переопределяется впотомках. Методы, вызываемые им, делятся на следующие группы.• Конкретные операции, реализация которых известна на момент написания метода и недолжна изменяться.• Абстрактные операции, которые представляют собой изменяемые части алгоритма.Они не имеют реализации и должны определяться в каждом классе-потомке всоответствии с теми вариациями, которые он вносит в базовый алгоритм.• Операции-перехватчики, или зацепки (hook operations), которые также представляютсобой изменяемые элементы алгоритма, но имеют некоторую реализацию поумолчанию, записанную в базовом классе.