Pull to refresh

Comments 22

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

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

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

А по поводу паттерна, могу сказать, что патерны редко используются из книги. Всегда используется своя вариция паттерна.
Вот ещё одна «своя» вариация на тему Observer Pattern.
Sign up to leave a comment.

Articles