Лекция
Привет, Вы узнаете о том , что такое издатель-подписчик, Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое издатель-подписчик, publisher-subscriber, pub/sub , настоятельно рекомендую прочитать все из категории Объектно-ориентированное программирование ООП.
издатель-подписчик (англ. publisher-subscriber или англ. pub/sub ) — поведенческий шаблон проектирования передачи сообщений, в котором отправители сообщений, именуемые издателями (англ. publishers), напрямую не привязаны программным кодом отправки сообщений к подписчикам (англ. subscribers). Вместо этого сообщения делятся на классы и не содержат сведений о своих подписчиках, если таковые есть. Аналогичным образом подписчики имеют дело с одним или несколькими классами сообщений, абстрагируясь от конкретных издателей.
Шаблон издатель-подписчик представляет собой расширение шаблона наблюдатель, в который добавлено описание канала событий (англ. event channel), специально предназначенного для оповещения о событиях .
Шаблон издатель-подписчик наряду с близкой ему концепцией очереди сообщений содержится в арсенале средств событийно-ориентированного промежуточного слоя ПО большой системы. Большинство систем передачи сообщений поддерживают в своем API как и модель издатель-подписчик, так и очередь сообщений. Примером такой системы может быть Java Message Service (JMS) .
Этот шаблон обеспечивает большую масштабируемость и более динамичную топологию сети.
Паттерн Наблюдатель предлагает хранить внутри объекта издателя список ссылок на объекты подписчиков, причем издатель не должен вести список подписки самостоятельно. Он предоставит методы, с помощью которых подписчики могли бы добавлять или убирать себя из списка.
Подписка на события.
Теперь самое интересное. Когда в издателе будет происходить важное событие, он будет проходиться по списку подписчиков и оповещать их об этом, вызывая определенный метод объектов-подписчиков.
Издателю безразлично, какой класс будет иметь тот или иной подписчик, так как все они должны следовать общему интерфейсу и иметь единый метод оповещения.
Оповещения о событиях.
Увидев, как складно все работает, вы можете выделить общий интерфейс, описывающий методы подписки и отписки, и для всех издателей. После этого подписчики смогут работать с разными типами издателей, а также получать оповещения от них через один и тот же метод.
В модели издатель-подписчик подписчики обычно получают только подмножество всех опубликованных сообщений. Процесс отбора сообщений для получения и их обработка называется фильтрацией. Существуют две основных формы фильтрации: основанная на теме (англ. topic) и основанная на содержимом.
В системе, основанной на теме, сообщения публикуются в «темах» или именованных логических каналах. Подписчики в таких системах будут получать все сообщения, опубликованные в темах, на которые они подписались, и все подписчики, подписавшиеся на одну и ту же тему, будут получать те же самые сообщения. Издатель отвечает за определение классов сообщений, на которые подписываются подписчики.
В системе, основанной на содержимом, сообщения доставляются подписчикам только в том случае, если атрибуты или содержимое этих сообщений допускаются подписчиком. Об этом говорит сайт https://intellect.icu . В данной системе подписчик отвечает за классификацию сообщений.
Некоторые системы представляют собой гибрид между этими двумя системами: издатель отправляет сообщения в тему, в то время как подписчики регистрируют подписку, основанную на содержимом для одной или более тем.
Во многих реализациях шаблона издатель-подписчик издатель отправляет сообщения посреднику, который может быть брокером сообщений или шиной. В таком случае подписчики регистрируют подписку с этим брокером, осуществляющим фильтрацию. Брокер, как правило, осуществляет хранение сообщений и пересылку для маршрутизации сообщения от издателя к подписчику. Кроме того, брокер может устанавливать приоритеты сообщениям в очереди сообщений перед их маршрутизацией.
Подписчики могут подписываться на определенные сообщения на этапе написания кода, во время инициализации приложения или во время выполнения. В системах с пользовательским графическим интерфейсом подписчики могут подписываться вручную с помощью команд (таких как нажатие на кнопке). Некоторые фреймворки и ПО используют для подписки конфигурационные файлы в формате XML или JSON, такие файлы читаются во время инициализации. Другие программные системы могут добавлять или удалять подписку во время выполнения, например триггеры баз данных или RSS.
Большинство распределенных систем реального времени стандарта DDS не используют брокеров. Вместо этого каждый издатель и подписчик совместно используют мета-данные друг о друге. Издатель и подписчик кэшируют эту информацию локально и маршрутизируют сообщения, основываясь на этих сведениях.
Шаблон издатель-подписчик впервые публично был представлен в 1987 году Ассоциацией по вычислительной технике (ACM) на симпозиуме «Принципы операционных систем» конференции SOSP '87, в статье «Применение виртуальной синхронности в распределенных системах. 123—138» как часть новостной подсистемы Isis Toolkit.
При масштабировании приложения, которое подписывается на раздел, необходимо работать с конкурирующими потребителями. Только один экземпляр приложения должен работать с сообщением, отправленным в раздел. К счастью, можно использовать систему, которая обрабатывает эту проблему. Когда несколько экземпляров службы с одним и тем же идентификатором приложения подписываются на раздел, она доставляет каждое сообщение только одному из них.
Когда после изменения состояния одного объекта требуется что-то сделать в других, но вы не знаете наперед, какие именно объекты должны отреагировать.
Описанная проблема может возникнуть при разработке библиотек пользовательского интерфейса, когда вам надо дать возможность сторонним классам реагировать на клики по кнопкам.
Паттерн Наблюдатель позволяет любому объекту с интерфейсом подписчика зарегистрироваться на получение оповещений о событиях, происходящих в объектах-издателях.
Когда одни объекты должны наблюдать за другими, но только в определенных случаях.
Издатели ведут динамические списки. Все наблюдатели могут подписываться или отписываться от получения оповещений прямо во время выполнения программы.
Разбейте вашу функциональность на две части: независимое ядро и опциональные зависимые части. Независимое ядро станет издателем. Зависимые части станут подписчиками.
Создайте интерфейс подписчиков. Обычно в нем достаточно определить единственный метод оповещения.
Создайте интерфейс издателей и опишите в нем операции управления подпиской. Помните, что издатель должен работать только с общим интерфейсом подписчиков.
Вам нужно решить, куда поместить код ведения подписки, ведь он обычно бывает одинаков для всех типов издателей. Самый очевидный способ — вынести этот код в промежуточный абстрактный класс, от которого будут наследоваться все издатели.
Но если вы интегрируете паттерн в существующие классы, то создать новый базовый класс может быть затруднительно. В этом случае вы можете поместить логику подписки во вспомогательный объект и делегировать ему работу из издателей.
Создайте классы конкретных издателей. Реализуйте их так, чтобы после каждого изменения состояния они отправляли оповещения всем своим подписчикам.
Реализуйте метод оповещения в конкретных подписчиках. Не забудьте предусмотреть параметры, через которые издатель мог бы отправлять какие-то данные, связанные с происшедшим событием.
Возможен и другой вариант, когда подписчик, получив оповещение, сам возьмет из объекта издателя нужные данные. Но в этом случае вы будете вынуждены привязать класс подписчика к конкретному классу издателя.
Клиент должен создавать необходимое количество объектов подписчиков и подписывать их у издателей.
Цепочка обязанностей, Команда, Посредник и Наблюдатель показывают различные способы работы отправителей запросов с их получателями:
Разница между Посредником и Наблюдателем не всегда очевидна. Чаще всего они выступают как конкуренты, но иногда могут работать вместе.
Цель Посредника — убрать обоюдные зависимости между компонентами системы. Вместо этого они становятся зависимыми от самого посредника. С другой стороны, цель Наблюдателя — обеспечить динамическую одностороннюю связь, в которой одни объекты косвенно зависят от других.
Довольно популярна реализация Посредника при помощи Наблюдателя. При этом объект посредника будет выступать издателем, а все остальные компоненты станут подписчиками и смогут динамически следить за событиями, происходящими в посреднике. В этом случае трудно понять, чем же отличаются оба паттерна.
Но Посредник имеет и другие реализации, когда отдельные компоненты жестко привязаны к объекту посредника. Такой код вряд ли будет напоминать Наблюдателя, но все же останется Посредником.
Напротив, в случае реализации посредника с помощью Наблюдателя представим такую программу, в которой каждый компонент системы становится издателем. Компоненты могут подписываться друг на друга, в то же время не привязываясь к конкретным классам. Программа будет состоять из целой сети Наблюдателей, не имея центрального объекта-Посредника.
Исследование, описанное в статье про издатель-подписчик, подчеркивает ее значимость в современном мире. Надеюсь, что теперь ты понял что такое издатель-подписчик, publisher-subscriber, pub/sub и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Объектно-ориентированное программирование ООП
Комментарии
Оставить комментарий
Объектно-ориентированное программирование ООП
Термины: Объектно-ориентированное программирование ООП