Почему прослушиватель изменений свойств вместо наблюдаемого

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

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

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

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

Привет

ОТВЕТЫ

Ответ 1

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

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

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

Ответ 2

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

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

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

Ответ 3

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

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

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

Ответ 4

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

Ответ 5

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