Паттерн "Наблюдатель"

• Обсуждение паттерна "наблюдатель" и его применение в моделировании человека.  

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

• Агрегация объектов, таких как свет и музыка, с человеком.  

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

• Необходимость передачи ссылок на объекты в конструктор человека.  

• Проблемы с использованием класса "персон" в других программах.  

• Необходимость создания нового класса "умный дом" для управления светом, музыкой и окнами.  

• Вопросы о том, как "умный дом" узнает о состоянии человека.  

• Обсуждение возможных решений и их недостатков.  

• Пример с метеостанцией и её датчиками.  

• Необходимость расширения программы для отображения различных параметров.  

• Обсуждение необходимости добавления новых типов датчиков.  

• Проблемы с реализацией расширяемости через добавление полей в класс.  

• Проблемы с зависимостью класса "вз дейта" от конкретных классов индикаторов.  

• Необходимость реализации единого интерфейса для датчиков.  

• Жестко записанные поля в классах не позволяют добавлять или удалять элементы во время выполнения программы.  

• Пример: добавление или удаление индикаторов требует изменения кода.  

• Переменные аспекты архитектуры, такие как индикаторы, должны быть инкапсулированы.  

• Изменения в программе требуют внесения изменений в код.  

• Все индикаторы должны иметь метод обновления с тремя параметрами.  

• Пример: разные классы индикаторов имеют общий интерфейс для обновления.  

• Паттерн "Наблюдатель" позволяет объектам автоматически оповещать других об изменении состояния.  

• Пример: субъект управляет состоянием и оповещает наблюдателей об изменениях.  

• Субъект хранит коллекцию указателей на наблюдателей.  

• При изменении состояния субъект вызывает метод обновления у наблюдателей.  

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

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

• Субъектом может быть кнопка, которая может использоваться в разных программах без модификации.  

• Субъекты и наблюдатели могут использоваться независимо друг от друга, что делает изменения в одних объектах безопасными для других.  

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

• Меньше зависимостей между объектами улучшает гибкость и ремонтопригодность.  

• Введение интерфейса Observer и абстрактного класса Observerable.  

• Объекты могут добавлять и удалять наблюдателей через методы addObserver и removeObserver.  

• Пример использования Observer для отображения статистики и прогноза погоды.  

• Методы notifyObservers и onNotification вызываются при изменении состояния.  

• Интерфейс Observer может иметь несколько методов, вызываемых при изменении состояния.  

• Метод update может принимать параметры для уточнения изменений.  

• Три модели взаимодействия: вытягивание, проталкивание и явная подписка.  

• Модель вытягивания передает минимум информации, что требует дополнительных запросов от наблюдателей.  

• Субъект передает дополнительную информацию, что упрощает работу наблюдателей.  

• Недостаток: снижение повторного использования кода.  

• Наблюдатели могут явно указывать, на какие события они хотят подписаться.  

• Субъект уведомляет только подписанных наблюдателей.  

• Один наблюдатель может следить за несколькими субъектами.  

• Субъекты могут передавать информацию о себе в параметрах метода update.  

• Умный дом хранит список наблюдателей для управления освещением и другими функциями.  

• Методы wakeUp и sleep вызывают уведомления у наблюдателей.  

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

• Клиенты могут откладывать уведомления до завершения серии изменений, что требует дополнительных действий.  

• Введение класса NotificationManager для централизованного управления уведомлениями.  

• NotificationManager отслеживает изменения состояния и уведомляет наблюдателей.  

• Клиент вызывает методы у субъекта, изменяя его состояние.  

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

• Использование setTimeout или debounce для отправки уведомлений с задержкой.  

• Субъект не должен удалять подписчиков раньше себя, чтобы избежать висячих ссылок.  

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

• В языках со сборщиком мусора эта проблема решается автоматически.  

• Субъект вызывает внешний код, обновляя состояние наблюдателей.  

• Проблемы с рекурсией и согласованностью состояния при обновлении наблюдателей.  

• Паттерн Template Method помогает обеспечить согласованное состояние.  

• Пример программы, наблюдающей за курсом валюты.  

• Использование функций вместо интерфейсов для наблюдателей.  

• Подписка и отписка через токены для предотвращения переполнения.  

• Класс CurrencyRate хранит текущий курс и наблюдателей.  

• Метод setRateChange вызывает наблюдателей при изменении курса.  

• Метод getRate возвращает текущий курс.  

• Метод removeChangeObserver удаляет наблюдателя по токену.  

• Создание класса "Ever Rate Monitor" для отслеживания среднего курса валюты.  

• Основной принцип: суммировать значения и делить на количество.  

• Передаем интерфейс "Carren Rate" в конструктор.  

• В деструкторе отписываемся от интерфейса для предотвращения утечек памяти.  

• В методе "onRateChange" увеличиваем сумму и количество уведомлений.  

• Делим сумму на количество для вычисления среднего курса.  

• Создание объекта "Stock" для подписки на изменения курса.  

• Пример использования "push" модели уведомлений.  

• Пример с использованием лямбда-функций для подписки.  

• Создание "Ever Calint Monitor" для демонстрации разрушения блока.  

• Пояснение, как работает разрушение блоков и отписка от уведомлений.  

• Проблемы с деструктором и необходимость автоматической отписки.  

• Использование сигналов и слотов для упрощения кода.  

• Введение интерфейса "Rate Observer" из библиотеки Boost.  

• Использование объекта "Connection" для автоматической отписки.  

• Хранение объекта "Connection" в переменной для упрощения кода.  

• Вопросы по реализации и ответы на них.  

• Пояснение, что отписка происходит при разрушении объекта "Connection".  

• Паттерн Observer позволяет хранить и автоматически удалять соединения.  

• Можно избежать рекурсивных вызовов сигналов.  

• Наблюдатели могут возвращать значения, которые влияют на работу субъекта.  

• Пример: робот, который уведомляет наблюдателей о цели, и решает, что с ней делать.  

• Умный дом может уведомлять владельца о событиях, таких как обнаружение движения.  

• Паттерн Observer используется в веб-приложениях, например, для создания новых каналов при регистрации пользователя на YouTube.  

• Пример: охранник, который следит за объектом и реагирует на его действия.  

• Пример: программа для архивирования файлов, которая отображает прогресс в виде индикатора.  

• Вопросы: Может ли один объект быть одновременно наблюдателем и наблюдаемым?  

• Ответ: Да, через множественное наследование или функциональные конструкции.  

• Пример: умный дом может быть наблюдателем, уведомляя пожарную охрану о высоком уровне угарного газа.  

• Важно минимизировать влияние изменений в одной части программы на другие.  

• Пример: диаграммы UML для визуализации зависимостей между объектами.  

• Пример: изменение персон влияет на персон обзервер, но не наоборот.  

• Вопросы: Есть ли циклические зависимости?  

• Ответ: Нет, кроме связи между персон обзервер и персон.  

• Вопросы: Как избежать циклических зависимостей?  

• Ответ: Ввести интерфейс ай персон, чтобы избежать зависимости от персон обзервер.