Lecture08 (1133565), страница 2
Текст из файла (страница 2)
Чаще всего при этом достаточно много компонентовзависит от небольшого набора данных. Можно было бы связать их явно, введя обращенияко всем компонентам, которые должны знать об изменениях, при каждом внесенииизменений, но полученная система станет очень жесткой. Добавление нового компонентапотребует сделать изменения во всех местах, от которых он зависит. Предлагаемое врамках данного образца решение основано на гибкой связи между субъектом (от которогозависят другие компоненты) и этими зависимыми компонентами, называемымиподписчиками. Здесь нужно принимать во внимание следующие факторы.Действующие силы.• Об изменениях в состоянии некоторого компонента должны узнавать один илинесколько других компонентов.• Количество и конкретный вид компонентов, которые должны оповещаться об этихизменениях, заранее не известны или могут быть изменены во время работыприложения.• Проведение зависимыми компонентами время от времени явных запросов опроизошедших изменениях неэффективно.• Источник информации (субъект или издатель) не должен быть тесно связан сосвоими подписчиками или зависим от них.Решение.
Компонент, от которого зависят другие, берет на себя функции издателя. Онпредоставляет интерфейс для регистрации компонентов-подписчиков, заинтересованных винформации о его изменениях, и хранит множество зарегистрированных подписчиков. Приизменениях он оповещает их с помощью вызова предназначенного для этого методаupdate().observersPublisher0..*attach (Subscriber)detach (Subscriber)notify ()Subscriberupdate ()forall o in observers{ o.update(); }getState ()ConcreteSubscriberpublisherupdate ()Рисунок 54.
Структура классов подписчиков и издателя.Структура. Основными компонентами являются издатель (или субъект) и подписчики(или наблюдатели). Подписчики реализуют общий интерфейс, у которого имеется методupdate() для оповещения подписчика о том, что в состоянии издателя произошлиизменения. Издатель хранит множество подписчиков, позволяет регистрировать илиудалять их из этого набора. При возникновении изменений он оповещает все элементыэтого множества при помощи метода update().Динамика.
Можно использовать два вида обновления подписчиков: издатель сам можетсообщать им о том, какие именно изменения произошли (схема проталкивания, pushmodel), или после получения уведомления подписчик сам обращается к издателю, чтобыузнать, что именно изменилось (схема вытягивания, pull model). Вторая схема значительноболее гибкая, она позволяет подписчикам получать только необходимую им информацию,в то время как согласно первой схеме каждый подписчик получает всю информацию опроизошедших изменениях.PubllisherchangeSubscriber 1Subscriber 2notifyupdateget stateupdateget stateРисунок 55.
Сценарий оповещения об изменениях по схеме вытягивания.Реализация. Основные шаги реализации следующие.• Определить протокол обновления — будет ли использоваться простой методupdate() или в качестве его параметров нужно будет передавать изменившийсяобъект-издатель и данные произошедшего изменения.• Определить схему обновления одного подписчика: на основе проталкивания или наоснове вытягивания информации.• Определить отображение издателей на подписчиков. Если издателей много, аподписчиков мало, то хранение множеств подписчиков для каждого издателя можетбыть неэффективным — для экономии памяти за счет времени поиска подписчиковможно использовать отдельную таблицу, отображающую издателей на подписчиков.• Обеспечить гарантии целостности состояния издателя перед оповещениемподписчиков.• Обеспечить гарантии аккуратного удаления объекта-подписчика из системы —нужно, чтобы он был удален из всех списков оповещений.• Если семантика обновлений сложна, например, если подписчик зависит отнескольких издателей, которые могут изменяться в рамках одной операции, то,возможно, потребуется выделить такие сложные связи в отдельный компонент,называемый менеджером изменений (change manager).
Такой компонент должен самхранить отображение между издателями и подписчиками, определять стратегиюпроведения обновления и обновлять всех зависимых подписчиков по запросу отиздателя. В качестве стратегии обновления может выступать механизм,гарантирующий подписчику получение только одного уведомления, еслиизменяются несколько издателей, от которых он зависит.Следствия применения образца.Достоинства• Слабая связанность между издателем и подписчиками — издатель знает только, чтоу него есть несколько подписчиков с одинаковым интерфейсом.• Удобным образом, не зависящим от числа участников, поддерживаютсяшироковещательные оповещения.Недостатки• Низкая производительность в случае большого количества подписчиков — даженебольшое изменение требует оповестить их всех, и каждый из них будет пытатьсяпровести обновление своего состояния.• Неэффективное использование информации из-за необходимости оповещать всехподписчиков, даже тех, для которых выполненные изменения несущественны.Кроме того, подписчик может зависеть от нескольких издателей и не знать, какойименно издатель оповещает его об изменении.
Чтобы исправить эту ситуацию,необходимо внесение изменений в протокол оповещения — предоставлениедополнительной информации, как об изменившемся издателе, так и о видеизменения.Примеры. Один из примеров мы уже видели — в рамках более широкого стиля «данныепредставление-обработка» представления и обработчики являются подписчиками поотношению к модели-издателю.Вариант этого образца с введением менеджеров изменений описан под названием «каналсобытий» (Event Channel) в спецификации службы оповещения о событиях в стандартеCORBA [2].ИдиомыИдиома представляет собой типовое решение, определяющее специфическую структуризациюэлементов кода на некотором языке программирования. Чаще всего это некоторый «трюк», спомощью которого можно придать программе на данном языке нужные свойства. При этомидиома может оказаться специфичной для языка и не иметь аналога в других языках.
Кроме того,очень часто удачные идиомы при развитии языков программирования превращаются в новыесинтаксические конструкции, делающие такую идиому ненужной.Далее мы увидим примеры таких идиом в виде соглашений о построении кода компонентовJavaBeans, превратившихся в C# в элементы языка.В этой лекции мы рассмотрим в качестве примера идиому «шаблонный метод» [3].Шаблонный методНазвание. Шаблонный метод (template method).Назначение. Фиксация общей схемы некоторого алгоритма, имеющего много вариантов, спредоставлением возможности реализовать эти варианты за счет переопределенияотдельных его шагов, без изменения схемы в целом. При использовании этой идиомынужно принимать во внимание следующие факторы.Действующие силы.• Инвариантные части алгоритма нужно записать один раз и переиспользовать,изменяя только варьирующиеся шаги и элементы.• Иногда такие инвариантные части еще нужно выделить, чтобы сделать болеепонятным и более удобным для сопровождения код нескольких классов,реализующих близкие по назначению методы.• Многие алгоритмы при их практическом использовании могут зависеть от большогочисла факторов, изменяющихся гораздо чаще, чем общая схема такого алгоритма(вспомните принцип разделения политик и алгоритмов).Решение.
Общая схема алгоритма, которую нужно зафиксировать, помещается вабстрактный класс в виде метода, код которого реализует эту схему. В тех местах, гденеобходимо использовать какой-то варьирующийся элемент алгоритма, этот методобращается к другому методу данного класса, который можно переопределить в классахпотомках.Структура. Метод, реализующий основную схему алгоритма, называется шаблоннымметодом.
Он пишется один раз в абстрактном базовом классе и не переопределяется впотомках. Методы, вызываемые им, делятся на следующие группы.• Конкретные операции, реализация которых известна на момент написания метода и недолжна изменяться.• Абстрактные операции, которые представляют собой изменяемые части алгоритма.Они не имеют реализации и должны определяться в каждом классе-потомке всоответствии с теми вариациями, которые он вносит в базовый алгоритм.• Операции-перехватчики, или зацепки (hook operations), которые также представляютсобой изменяемые элементы алгоритма, но имеют некоторую реализацию поумолчанию, записанную в базовом классе.
Эти операции могут переопределяться вклассах-потомках, если представляемые ими элементы алгоритма нужно изменить посравнению с имеющейся реализацией по умолчанию.• Фабричные методы (factory methods), предназначенные для создания объектов, которыесвязаны с работой конкретного варианта алгоритма. Они реализуются по образцу, такженазываемому «фабричный метод». Суть такого метода в том, что при его вызове мыточно не знаем, объект какого конкретного класса будет создан — это зависит оттекущей конфигурации системы.Динамика.
Типичный сценарий работы шаблонного метода показан на Рис. 56. Длянаглядности на этой диаграмме операции, выполняемые в одном объекте, разделены междудвумя виртуальными объектами: первый представляет все действия, выполняемые в рамкахабстрактного класса, определяющего шаблонный метод, а второй — те действия, которые(пере)определяются в конкретном подклассе.Реализация. Основные шаги реализации следующие.• Определить основные шаги алгоритма. Определить набор данных, которыми онпользуется.• Выделить среди шагов алгоритма те, которые зависят от конкретных политик.Определить для каждого такого шага абстрактный метод.Abstract Class Methodsmethod()Concrete Class Methodsconcrete operationabstract operation 1default hook operationabstract operation 2overriden hook operationРисунок 56.
Сценарий работы шаблонного метода.•Выделить среди данных, которыми пользуется алгоритм, те, чья структура зависитот политик или конкретного варианта алгоритма. Определить для порождения такихданных фабричные методы, а для операций над ними — абстрактные методы. Дляих представления могут понадобиться дополнительные классы, но изменяемая частьданных должна, по возможности, находиться в абстрактном классе, определяющемшаблонный метод.• Реализовать общую схему алгоритма в теле шаблонного метода. Выделить егоэлементы, используемые несколько раз или представляющие собой отдельныеоперации, в отдельные методы абстрактного класса.• Определить, какие дополнительные возможности по вариации поведения алгоритмамогут понадобиться.