Эндрю Хант - Программист-прагматик. Путь от подмастерья к мастеру

Начнем с концепции события. Событие представляет собой специальное сообщение, в котором говорится: «Только что случилось нечто интересное» (разумеется, с точки зрения наблюдателя). Мы можем использовать события, чтобы сигнализировать одному объекту об изменениях, произошедших с другим объектом, в которых последний может быть заинтересован.

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

Однако при использовании событий необходимо соблюдать некоторую осторожность. Например, в одной из ранних версий Java одна подпрограмма получила все события, предназначенные для специфического приложения. Это не совсем подходит для облегчения сопровождения или развития программы.

Почему считается дурным тоном пропускать все события через одну-единственную программу? Потому что при этом нарушается инкапсулирование объекта – теперь этой подпрограмме приходится получать сокровенную информацию о взаимодействии между многими объектами. Это также способствует увеличению связывания, а мы пытаемся его уменьшить. Поскольку и самим объектам приходится получать информацию об этих событиях, то, по всей вероятности, вы собираетесь нарушить принцип DRY, принцип ортогональности и, может быть, некоторые разделы Женевской конвенции. Быть может, вам случалось видеть подобные программы – их доминантой является огромный оператор case или многообразная конструкция if-then. Мы можем сделать это изящнее.

Объекты должны иметь возможность регистрации только для приема событий, которые им нужны, и никогда не должны посылать события, которые им не нужны. Мы не хотим, чтобы наши объекты подверглись спаммингу! Вместо этого мы можем воспользоваться протоколом типа «публикация и подписка», который представлен на рисунке 5.4 с помощью диаграммы последовательностей на языке UML [34] Более подробная информация содержится в описании шаблона Observer в книге [GHJV95]. .

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

Рис. 5.4. Протокол «Публикация и подписка»

Если нам интересны определенные события, которые генерируются объектом Publisher (Издатель), то все, что нам нужно, – это зарегистрироваться. Объект Publisher отслеживает все заинтересованные объекты Subscriber (Подписчик); когда объект Publisher генерирует событие, представляющее интерес, он, в свою очередь обращается к каждому объекту Subscriber, извещая их о том, что данное событие произошло.

На эту тему существует несколько вариаций, отражающих другие стили обмена данными. Объекты могут использовать протокол «Публикация и подписка» на одноранговой основе (как показано выше), а также «программную шину», где централизованный объект поддерживает базу данных «слушателей» и осуществляет соответствующую диспетчеризацию. Вы даже можете получить схему, в которой критические события транслируются ко всем «слушателям» – как зарегистрированным, так и незарегистрированным. Одна из возможных реализаций событий в распределенной среде иллюстрируется службой сообщений CORBA, описанной во врезке «Служба событий CORBA» (см. ниже).

Можно использовать протокол «Публикация и подписка» для реализации очень важного принципа проектирования: отделения самой модели от ее визуальных представлений. Начнем с примера графического интерфейса, используя конструкцию на языке Smalltalk, где зародилась данная концепция.

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

Служба событий CORBA позволяет объектам-участникам отправлять и получать уведомления о событиях через общую шину, так называемый канал событий. Канал событий принимает решение по обработке событий, а также осуществляет разделение производителей и потребителей событий. Он работает в двух основных режимах: «проталкивание» и «вытягивание».