В прошлом посте я коснулся темы шаблонов проектирования Наблюдатель и Издатель-Подписчик.
Постараюсь разобрать первый из двух, а потом рассмотрим и второй.
Как известно, шаблоны проектирования бывают:
⭐️ Порождающие
⭐️ Структурные
⭐️ Поведенческие
Наблюдатель является поведенческим шаблоном проектирования, который позволяет одним объектам следить и реагировать на события, происходящие в других объектах, благодаря механизму подписки.
Иными словами, я как часть программы, подписываюсь на изменения в определенных объектах, и меня, в случае таких изменений, оповещают. Мол, братан, там чет поменялось, ты просил пнуть тебя, если че-то поменяется.
Но на кой черт мне просить оповещать меня? Ситуация, скажем прямо, не повседневная.
Для ответа на вопрос "
Представьте себе диспетчера, который сидит перед монитором, и видит на нем как разная техника ездит по дорогам.
И вдруг, о Боже! Один экскаватор замигал красными огнями. Код красный, код красный, экскаватор в беде. Пукан диспетчера взрывается 😫 , что побуждает его совершить определенные действия 🛠.
Теперь рассмотрим эту же ситуацию изнутри. Диспетчер видит технику. Как эта информация поступает к нему? Он должен видеть изменения координат каждой машинки 🚗.
Вариантов реализовать это 2.
Первый вариант. Фронт шлет запросы на сервер. Много запросов. И спрашивает: "Чувак, че нить поменялось? А теперь? А теперь?" И сервер на каждый такой запрос говорит: "Да, поменялось, вот эти машинки были тут, теперь они здесь. А еще у экскаватора припадок".
Это не очень эффективно, так как ну много запросов, нагрузка большая.
Специально для таких кейсов умные ребята в странных свитерах придумали другой протокол. WebSocket
Веб-сокет это такой протокол, при котором между двумя системами открывается канал для передачи сообщений, который длительное время может быть открытым .
В отличии от HTTP, где у нас всегда есть запрос-ответ, в веб-сокете это совсем не обязательно. Возможно отправлять безграничное множество сообщений от одного сервиса в другой и наоборот. Например 10 в одну сторону 20 в другую. Количество ничем не ограничено, как и очередность 💌✉️💌
Это позволяет отправлять информацию на фронт, не дожидаясь от него запроса на получение этой информации.
Теперь наденем резиновые перчатки 🎮 и погрузимся еще глубже в эту ситуацию.
🎮 Заглянем в бэкенд 🎮
Представьте себе класс, отвечающий за отправку веб-сокет сообщений во все веб-сокет сессии.
Но как этот класс должен понимать, что ему нужно отправить сообщение? Должен ли он постоянно мониторить состояние техники? Должен ли он постоянно самолично интересоваться состоянием каждой техники? Это было бы сложно.
Именно тут на сцену выходит
Observer - Наблюдатель
Шаблон, который позволит серверу держать фронт в актуальном состоянии, и разработчику не взорвать мозг при проектировании сложной логики.
Что произойдет?
Класс, который отвечает за отправку веб-сокет сообщений, просто единожды подпишется на изменения состояний техники, а когда эти изменения произойдут, наш класс будет оповещен, и отправит сообщение в веб-сокет сессию.
Согласен, можно было бы придумать что попроще, но мне хотелось показать вам реальные задачи, которые решаются с помощью изучаемых вами материалов.
Теперь, попробуем обернуть все в код.
В примере сознательно допущены упрощения, для лучшего восприятия. Хороший пример данного шаблона вы можете найти здесь.