Comments 16
А как будет вызываться метод dChanged() в наблюдаемом классе?
Получается, что в методах aChanged() и bChanged() вы будете использовать оба итератора ATranslator и DTranslator? Как-то похоже больше на решение через реализацию, чем композицию. Наблюдаемый объект вообще не должен знать, что существуют два разных наблюдателя. В вашем случае для наблюдателей D я бы сделал иначе.
Получается, что в методах aChanged() и bChanged() вы будете использовать оба итератора ATranslator и DTranslator? Как-то похоже больше на решение через реализацию, чем композицию. Наблюдаемый объект вообще не должен знать, что существуют два разных наблюдателя. В вашем случае для наблюдателей D я бы сделал иначе.
А наблюдаемый класс, знает только о каком-то слушателе реализующий интерфейс AListener или DListener. В методах же aChanged() и bChanged() используется только один из «трансляторов».
В статье я явно не написал, что есть множество слушателей, которые взаимодействуют с наблюдателями, реализующими интерфейс AListener, а есть множество тех, которые взаимодействуют с наблюдателями, реализующими интерфейс DListener. И заставить вторые работать со слушателями реализующими только AListener не удастся, чего и добивались.
А как бы вы сделали?
В статье я явно не написал, что есть множество слушателей, которые взаимодействуют с наблюдателями, реализующими интерфейс AListener, а есть множество тех, которые взаимодействуют с наблюдателями, реализующими интерфейс DListener. И заставить вторые работать со слушателями реализующими только AListener не удастся, чего и добивались.
А как бы вы сделали?
для С++ имеется хорошая реализация такого механизма — сигналы и слоты в QT (есть и другие библиотеки ). Основная идея в том, что любой объект испускает в эфир сигналы о том, что что-то произошло, и любой желающий объект может этот сигнал прослушивать.
Реализуется это с помощью надстройки над языком — Meta Object Compiler, по сути препроцессор.
Реализуется это с помощью надстройки над языком — Meta Object Compiler, по сути препроцессор.
Эмммм, dependency injection, не?
Не. При DI внедряемый объект используется для вызова его основной логики (которая по хорошему должна быть единственной) и логика объекта, в который внедряется от него всё равно зависит как правило. Тут же слушатели подписываются на события, но на результат не влияют, просто делают свое дело (условно) параллельно. Области применения немного пересекаются, но только в простейших случаях. Хрестоматийный пример — при каком-то событии, например, вызов метода, нужно записать в лог сообщение или отправить его куда-нибудь. DI тут подойдет идеально, обеспечивая независимость от конкретной реализации лога или механизма отправки. Но как только нам нужно записать в лог и отправить сообщение, DI начинает потихоньку фэйлить и чем больше действий нужно совершить (записать в лог, отправить мыло, отправить смс, позвонить, сделать ролик для выкладывания на ютубе, отправить заметку в газету, вызвать корреспондента с ТВ, вызвать полицию для возбуждения дела и т. п.), тем больше фэйлит — зависмости хочешь-не хочешь нужно создавать в объекте, генрирующем события, что исключает, как минимум, его повторное использование, если в разных местах список действий разный.
Язык бы указали лучше в заголовке типа "… на примере Java( или C#? — сложно различать когда только книжки читал и хелловорлды писал :) )" или хотя бы в тегах.
«Всё это работает, но допустим в какой-то момент понимаем, что нужна возможность иметь разные способы уведомления слушателей. Например, уведомлять слушателей в разных порядках или в зависимости от каких-то условий некоторых слушателей не уведомлять о произошедших изменениях.»
Если это основная задача, то порядок уведомления слушателей — задача достойная к рассмотрению. Вариантов решения — куча.
А уведомлять слушателей в зависимости от каких то условий, задача в корне неверная, т.к. неправильно субъекту решать за наблюдателя важно ему это изменение или нет.
Если это основная задача, то порядок уведомления слушателей — задача достойная к рассмотрению. Вариантов решения — куча.
А уведомлять слушателей в зависимости от каких то условий, задача в корне неверная, т.к. неправильно субъекту решать за наблюдателя важно ему это изменение или нет.
А зачем собственно понадобился класс ListenerList? Замените его интерфейсом List<T extends *Listener> и получите то же самое
UFO just landed and posted this here
Мне одному кажется, что слушатель (Listener) и наблюдатель (Observer) это все-таки разные паттерны?
Sign up to leave a comment.
Паттерн Наблюдатель: списки и матрёшки из слушателей