爲什麼要改變property listener而不是可觀察

Question

直到我發現了observable（使用觀察者設計模式）並因此創建了一個使用它的小應用程序來解決我的問題之前，我一直有類設計問題。我很高興和自豪，我曾用一個很好的原則來解決問題。

現在，我即將開始我的主要應用和剛纔讀這

Making a JFrame and Observable Object

的海報建議不要使用可觀察到的爲什麼，而是告知使用propertychangelistenr？使用observable有什麼問題嗎？

Regards

Answer 1

Observer和Listener模式非常相似。但Observer有一個弱點：所有可觀察的都是一樣的。您必須實施基於instanceof的邏輯，並將對象轉換爲具體類型爲Observable.update()方法。

聽衆是不同的。有很多監聽器類型。例如鼠標監聽器，鍵盤監聽器等。每個人都有幾種回調方法（即keyPressed(),keyReleased()等）。所以，你永遠不必執行應該回答「是我的事件」這個問題的邏輯到事件處理程序中。

我認爲這就是爲什麼聽者模型更可取。

Answer 2

PropertyChangeListener是Observable模式的特例。那是我想，從設計的角度來看，這兩種解決方案都是很好的。同時據我記得PropertyChangeListener有一些內置的支持，因此它可能需要更少的編碼。 IE瀏覽器。見：http://download.oracle.com/javase/1.4.2/docs/api/java/beans/PropertyChangeSupport.html。

Answer 3

唯一正確的答案是「它取決於」。

Observable當你不關心對象有什麼變化時，它是很好的;你只想知道有些東西已更改並更新，例如對象屬性的緩存。它的界面太粗糙了，但如果你只是需要這樣的東西，它可能會節省時間。另一方面，正如AlexR注意到的那樣，你也不知道什麼類型的參數事先通過了（它甚至可以是一個null值！）。這使得它很難做一些有用的事情。正確的監聽器類可以有更豐富的API，但代價是將Listener接口和事件類添加到項目中。

Answer 4

區別在於你如何使用它們。大部分時間Observable的子類都沒有特別的實現 - 爲了得到一種新的Observable，你繼承它。另一方面，監聽器實現特定的接口（或頂級EventListener接口），因此必須實現某些方法。

Answer 5

DejanLekic和其他人現在可能已經意識到，Observable不是interface。這是Java.util.Observable的全部問題！

Observable的用戶必須從它繼承，而不是別的。

考慮Java.RMI或Listener events。