Почему прослушиватель изменений свойств вместо наблюдаемого
У меня возникли проблемы с дизайном класса, пока я не узнал об наблюдаемом (используя шаблон проектирования наблюдателя) и, таким образом, создал небольшое приложение, использующее его, которое решило мою проблему. Я был счастлив и горд тем, что использовал хороший принцип для решения проблемы.
Теперь я собираюсь запустить основное приложение и только что прочитал этот
Создание 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) и поэтому ДОЛЖНЫ реализовать определенные методы.
