Почему прослушиватель изменения свойства вместо наблюдаемого - PullRequest
15 голосов
/ 07 ноября 2011

У меня были проблемы с дизайном класса, пока я не узнал о наблюдаемом (используя шаблон проектирования наблюдателя) и, таким образом, создал небольшое приложение, которое решило мою проблему. Я был счастлив и горд, что использовал хороший принцип для решения проблемы.

Теперь я собираюсь запустить свое основное приложение и только что прочитал это

Создание JFrame и наблюдаемого объекта

Почему постеру рекомендовано не использовать наблюдаемый, а вместо этого указывать использовать propertychangelistenr? Есть ли проблемы с использованием наблюдаемых?

Привет

Ответы [ 5 ]

21 голосов
/ 07 ноября 2011

Шаблон Observer и Listener очень похожи. Но у Обозревателя есть слабость: все наблюдаемые одинаковы. Вы должны реализовать логику, основанную на instanceof и привести объект к конкретному типу в метод Observable.update().

Слушатели разные. Есть много типов слушателей. Например, прослушиватель мыши, клавиатура и т. Д. Каждый из них имеет несколько методов обратного вызова (например, keyPressed(), keyReleased() и т. Д.). Таким образом, вам никогда не придется реализовывать логику, которая должна отвечать на вопрос «это мое событие», в обработчик событий.

Я думаю, именно поэтому модель слушателя предпочтительнее.

7 голосов
/ 13 апреля 2012

DejanLekic и другие, вероятно, уже поняли, что Observable - это не interface.В этом вся проблема с Java.util.Observable!

Пользователь Observable должен наследовать от него, и ничего больше.

Рассмотрим Java.RMI или Listener events.

3 голосов
/ 07 ноября 2011

Единственный правильный ответ - "это зависит".

Observable хорошо, когда вам все равно, что меняется в объекте; вы только хотите знать, что что-то изменилось и обновить, например, кеш свойств объекта. Его интерфейс слишком грубый, но он может сэкономить время, если вам просто необходима такая вещь.

С другой стороны, как заметил AlexR, вы также не знаете, какой тип аргумента передается раньше (это может быть даже значение null!). Это усложняет работу с ним. Правильный класс слушателя может иметь более богатый API, но за счет добавления интерфейса Listener и класса событий в ваш проект.

1 голос
/ 07 ноября 2011

Разница в том, как вы их используете.В большинстве случаев подклассы Observable не имеют конкретной реализации - вы наследуете ее только для того, чтобы получить новый тип Observable.Слушатели, с другой стороны, реализуют определенный интерфейс (или интерфейс EventListener верхнего уровня) и поэтому ДОЛЖНЫ реализовывать определенные методы.

1 голос
/ 07 ноября 2011

PropertyChangeListener является частным случаем шаблона Observable.То есть я думаю, что оба решения хороши с точки зрения дизайна.Между тем, насколько я помню, PropertyChangeListener имеет некоторую встроенную поддержку, поэтому может потребоваться меньше кода.То есть.см .: http://download.oracle.com/javase/1.4.2/docs/api/java/beans/PropertyChangeSupport.html.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...