Разница между Observer, Pub / Sub и привязкой данных

В чем разница между шаблоном наблюдателя , публикацией / подпиской и привязкой данных ?

Я немного обыскал Stack Overflow и не нашел хороших ответов.

Я пришел к выводу, что привязка данных - это общий термин, и существуют разные способы его реализации, такие как шаблон наблюдателя или шаблон публикации / подписки. С помощью шаблона Observer Observable обновляет свои Observers. С Pub / Sub 0-многие издатели могут публиковать сообщения определенных классов, а 0-многие подписчики могут подписываться на сообщения определенных классов.

Существуют ли другие способы реализации «привязки данных»?

Вот мой взгляд на три:

Привязка данных

По сути, по сути это означает, что «значение свойства X объекта Y семантически связано со значением свойства A объекта B. Не делается никаких предположений относительно того, как Y знает или передает изменения объекта B.

Наблюдатель, или Наблюдаемый / Наблюдатель

Шаблон проектирования, с помощью которого объект наделен способностью извещать других о конкретных событиях - как правило, выполняется с использованием реальных событий, которые являются своего рода слотами в объекте в форме определенной функции / метода. Наблюдаемым является тот, кто предоставляет уведомления, а наблюдатель получает эти уведомления. В .net наблюдаемая может представлять событие, и наблюдатель подписывается на это событие с помощью крючка в форме «обработчика события». Не делается никаких предположений ни о конкретном механизме, по которому происходят уведомления, ни о количестве наблюдателей, которых может наблюдать один наблюдатель.

Pub / Sub

Другое имя (возможно, с более «широковещательной» семантикой) шаблона Observable / Observer, которое обычно подразумевает более «динамический» аромат - наблюдатели могут подписываться или отписываться от уведомлений, а один наблюдаемый может «кричать» нескольким наблюдателям. В .NET для этого можно использовать стандартные события, поскольку события являются формой MulticastDelegate, и поэтому могут поддерживать доставку событий нескольким подписчикам, а также поддерживать отмену подписки. Pub / Sub имеет немного другое значение в определенных контекстах, обычно включающее больше «анонимности» между событием и четным числом, чему может способствовать любое количество абстракций, обычно включающее некоторого «среднего человека» (такого как очередь сообщений), который знает все стороны, но отдельные стороны не знают друг о друге.

Связывание данных, Redux

Во многих «MVC-подобных» шаблонах наблюдаемое предоставляет некоторый способ «уведомления об изменении свойства», который также содержит информацию об определенном измененном свойстве. Наблюдатель неявный, обычно создаваемый платформой, и подписывается на эти уведомления с помощью некоторого синтаксиса привязки для конкретной идентификации объекта и свойства, а «обработчик события» просто копирует новое значение, потенциально вызывая любое обновление или логику обновления.

Привязка данных к Redux

Альтернативная реализация для привязки данных? Хорошо, вот глупый

• запускается фоновый поток, который постоянно проверяет привязанное свойство объекта.
• если этот поток обнаруживает, что значение свойства изменилось со времени последней проверки, скопируйте значение в связанный элемент.

Существует два основных различия между шаблонами Observer / Observable и Publisher / Subscriber:

1. Шаблон Observer / Observable в основном реализован синхронно , то есть наблюдаемый вызывает соответствующий метод всех своих наблюдателей, когда происходит какое-то событие. Издатель / Подписчик картина в основном реализована в асинхронном способе (использованием очереди сообщений).

2. В паттерне Наблюдатель / Наблюдаемый наблюдатели знают о наблюдаемом . Принимая во внимание, что в издателе / ​​подписчике издателям и подписчикам не нужно знать друг друга . Они просто общаются с помощью очередей сообщений.

Как вы правильно упомянули, привязка данных является общим термином, и его можно реализовать с помощью метода Observer / Observable или Publisher / Subscriber. Данные - это Издатель / Подписчик.

Я немного удивлен, что все ответы здесь пытались объяснить тонкую разницу между шаблонами Observer и Pub / Sub без каких-либо конкретных примеров. Бьюсь об заклад, большинство читателей до сих пор не знают, как реализовать каждый из них, читая один синхронно, а другой асинхронно.

Стоит отметить, что целью этих шаблонов является попытка отделить код

Observer - это шаблон проектирования, в котором объект (известный как субъект) поддерживает список объектов в зависимости от него (наблюдателей), автоматически уведомляя их о любых изменениях состояния.

Образец наблюдателя

Это означает, что у observable objectнего есть список, в котором он хранит все свои данные observers(которые обычно являются функциями). и может пройти этот список и вызвать эти функции, когда он чувствует себя хорошо.

см. этот пример шаблона наблюдателя для деталей.

Этот шаблон хорош, когда вы хотите прослушать любое изменение данных на объекте и соответственно обновить другие представления пользовательского интерфейса.

Но минусы - это наблюдаемые, которые поддерживают только один массив для хранения наблюдателей (в этом примере это массив observersList).

Это НЕ дифференцирует, как обновление инициировано, потому что у него есть только один notify function , которая запускает все функции, хранящиеся в этом массиве.

Если мы хотим сгруппировать обработчики наблюдателей на основе разных событий. Нам просто нужно изменить observersListэто Objectкак

var events = {
    "event1": [handler1, handler2],
    "event2": [handler3]
}

см. этот пример pubsub для деталей.

и люди называют эту вариацию как pub/sub. Таким образом, вы можете запускать различные функции в зависимости от eventsопубликованных вами.

Я согласен с вашим выводом об обоих шаблонах, тем не менее для меня я использую Observable, когда я нахожусь в одном процессе, и я использую Pub / Sub в межпроцессных сценариях, где все стороны знают только общий канал, но не стороны ,

Я не знаю других шаблонов, или позвольте мне сказать так, мне никогда не требовались другие шаблоны для этой задачи. Даже большинство сред MVC и реализации привязки данных обычно используют концепцию наблюдателя.

Если вы заинтересованы в межпроцессном взаимодействии, я рекомендую вам:

«Шаблоны корпоративной интеграции: проектирование, создание и развертывание решений для обмена сообщениями» - http://www.addison-wesley.de/9780321200686.html

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

Надеюсь, это поможет!