Комментарии 10
Зачем обрамлять Observer/Observable таком Г как Redux?? Уже же давным давно всё придумано, причем по человечески, с использованием getters/setters и это называется MobX. Ради приличия могли бы для демонстрации мощи Observer/Observable реализовать самую простую версию MobX и observer для реакт компонентов.
Ну да, mobx всяко лучше. Если забыть о том, что примером паттерна "Наблюдатель" mobx не является :-)
Если забыть о том, что примером паттерна "Наблюдатель" mobx не является :-)
Правда что ли? Вот прям не является вообще? Т.е. когда мы читаем observable свойства(getter отрабатывает) у объекта он не пушит в свой listeners под капотом функцию(колбэк прокинутый в action ,reaction) которую нужно будет вызвать при изменении этого самого свойства да?
Чтож, у меня для вас плохие новости.
Вот вам реализация "Наблюдателя" из википедии.
Не чего не напоминает? Ах да, да это же Event Emitter. Ах да, setter'ы в MobX по такому же принципу работают как и функция emit, оповещает наблюдателей/слушателей о том, что свойство наблюдаемого объекта изменилось. Какая досада.
А теперь поглядите на эту реализацию, и разглядите уже ключевые моменты паттерна:
- подписка явная;
- подписчиком является функция либо интерфейс с методами, но никак не объект с важным для источника событий состоянием;
- уведомления приходят подписчику каждый раз (либо строго один раз), но никак не в зависимости от соотношения состояний подписчика и источника.
Какая разница? Это детали реализации. Фундаментальный принцип сохраняется в любом случае.
Не надо в этом определении придираться к словам типа "класс", "объект" и т.п.
Всё это простой publisher/subscriber как не крути. Называть можно как угодно, но суть остается неизменной. Есть подписка на изменения, есть изменения и оповещение подписчиков об изменениях.
В Redux используется паттерн издатель-подписчик. В вашей статье описан тоже он.
Паттерн наблюдатель немного другой. По ссылке описана разница между ними:
https://medium.com/clean-code-channel/observer-vs-pub-sub-pattern-4fc1da35d11
В pub-sub паблишер и получатель не имеют ссылок друг на друга, коммуникация идёт чисто с помощью данных - сообщений.
В редаксе стор в этом месте знает всех своих подписчиков в лицо и сам же вызывает их на каждый свой чих. Т.е это observable в чистом виде.
Просто у паттерна название имхо не очень удачное, поскольку активная роль здесь у observable, который и дирижирует всем этим оркестром из observer'ов.
Да, как раз https://medium.com/clean-code-channel/observer-vs-pub-sub-pattern-4fc1da35d11 описано, что для издателя нужен какой-либо промежуточный компонент, который будет перенаправлять события издателя нужным подписчикам, то есть этот компонент скрывает детали функциональности модулей-подписчиков и издатель тем самым не взаимодействует напрямую с этими модулями. Возможно, он будет посложнее в реализации чем Наблюдатель...
В тексте, картинках и примерах взаимозаменямо используется слова observer и observable, хотя на самом деле они противоположные. Нехорошо.
Объяснение паттерна Наблюдатель на примере Redux