Как стать автором
Обновить

Комментарии 22

Голосовалка нужна — кто из троих изображенных на картинке VIP слушатель. :)
Я добавил пояснение в конце, в данном случае все трое являются випами =)
Вы их тех кто писал в учебном заведении сначала код, а потом по нему составлял блок схемы?
Я самоучка =) Этот паттерн юзали умные дядьки у нас на работе давным давно и названия он не имел.
В книге банды 4 его нету, в книге «шаблоны корпоративных приложений» фаулера тоже нету. В книге совершенный код его нету. В книгах про 20 советов тоже небыло.
Вот что бывает, если слушать машинный аккумулятор.
Есть в .NET такой класс — ObservableCollection, знаете?
Кхм, и как ObservableCollection поможет отслеживать изменения объектов которые в ней содержатся? Она ведь сигнализирует только при изменении списка, но не его элементов.
А как ваш паттерн реализует мониторинг изменения самих элементов?
My bad. Наивно предположил, что в RegisterItem происходит подписка на события объекта, и потом эти события передаются дальше с помощью ServiceStateChanged.
Как вы понимаете, это — не мой паттерн.
Если я изменю состояние любого IObject, сервис об этом не узнает.
Этот класс не решает тот паттерн который я описал, а даже если бы и решал то от этого паттерн не перестал бы быть паттерном.
Паттерны головного мозга. Смысл выделять это в отдельный паттерн? По-моему, это просто вариант реализации «наблюдателя» для конкретной задачи.

«VIP слушатель» — сразу думаешь о «наблюдателе» в котором есть VIP слушатель, приоритетнее остальных
Особенность с еще одним уведомлением об изменении нуууууууу… я бы не использовал такие опасные вещи, сайд эффекты будут восхитительными :)

Не принимайте близко к сердцу :)
У меня нет сердца, я программист. Снизу пояснил суть паттерна. Это модифицированный наблюдетель с возможностью получить события произошедшие до момента подписки.
Можете более подробно описать проблему, которую решает паттерн?
Это модифицированый наблюдатель, он решает проблему получения событий, которые произошли до подписки наблюдателя и соответствено были пропущены. В данном случае это события появления объектов в каком либо сервисе.
Наконец-то понял смысл. Записывать события и отправлять всю историю новым подписчикам. Но все ещё не ясно почему ВИП
Наблюдаемый объект обслуживает наблюдателя отдельно, формируя для него отдельный набор событий. Но повторюсь, название я придумал, если есть идеи других названий то велком.
«Наблюдательный пункт» («Observing Station»).
В момент подписки подписчика завалит уже вылупившимися объектами? С одной стороны вроде как и плохо (подписчик, возможно, ожидает объекты в момент их появления, а старые объекты его может не интересуют), с другой — хорошо (не надо перед подпиской запрашивать все объекты, синхронизаций нелепых меньше). Интересно, подумаю на досуге, но всё же что-то мне в этом недопуле объектов с прикрученной нотификацией о изменении не нравиццо.
Все верно, есть места где такое не нужно или опасно, а есть места где это очень удобно. Например если есть один симулятор и много обслуживающих слушателей, которые можно отключать и подключать в рантайме, то при использовании такого подхода разработка упрощается.
По хорошему, взять бы и создать на гитхабе репозиторий с проектом, а ещё бы и юнит тесты в него добавить.
Тогда бы и вопросов не возникало и было бы очень наглядно.

А по поводу паттерна, могу сказать, что патерны редко используются из книги. Всегда используется своя вариция паттерна.
Вот ещё одна «своя» вариация на тему Observer Pattern.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории