2009-01-13 47 views
0

As described in another question,我有一組Model對象和一組相關聯的Panel對象,允許用戶訪問Model對象中的數據。面板被註冊爲模型的PropertyChangeListeners,這樣如果其他內容更新模型中的值,它會觸發一個PropertyChangeEvent,面板接收它並知道重新同步模型中的值。 (目前我天真地只是更新所有的值,但是這樣做可以使智能更加靈活,只需要更改屬性。)你如何讓一個類監聽由其他類造成的PropertyChangeEvents,但不是這個類?

所有這些在模型被某些任意的未知源更新時都是有意義的,發生在我的應用程序。但是,大多數情況下,模型的屬性是由面板本身設置的。在這種情況下,現在我已經將面板掛接爲模型的PropertyChangeListeners,我的代碼做了一些毫無意義的事情:面板更新模型後,面板從模型接收到一個PropertyChangeEvent,並從中取出相同的值它最初發送給模型的模型。沒有更新需要發生,並且這沒有設計意義。

那麼我該如何註冊一個PropertyChangeListener,然後說「當我是他們的源時,不要通知我PropertyChangeEvents?」 (請注意,我無法通過調用PropertyChangeEvent.getSource()來回答這個問題;它會給我我的模型,而不是首先發送該值的面板;沒有辦法查看此內容並告訴更改了屬性)

回答

3

在所有的現實中,你是否真的在乎你是否讓這個事件對你回擊?它允許你處理模型在面板外進行更改的任何時間,並且在檢查是否真的需要更新值時確實沒有太多的開銷。

PropertyChangeEvent包含要更改的屬性以及舊值和新值。您可以檢查每個傳入事件,以查看面板中的值是否與新值相同,如果它丟棄該事件。模型應該告訴每個人在每次改變PropertyChangeEvents時都要監聽PropertyChangeEvent,否則它需要知道正在收聽的對象太多。

無論你做什麼,不要創建屬性更改事件監聽器循環。如果你不是非常小心的話,你最終會遇到一個非常容易結束的情況。

1

我不認爲在運行期間不必要的重繪會產生任何可測量的損害。所以從這個角度來看,不需要改變代碼。在這種情況下,你應該決定考慮設計/架構。你說:

...,這讓這一切的發生沒有設計感...

,但它確實! 如果要避免重繪,必須將源(面板)添加到更改模型的方法的參數中,將其放入更改事件並在評估事件時考慮該參數再次,這會讓你的代碼更加複雜。想想你還有什麼要做,如果有兩個同一個面板的實例,一個改變了模型,一個在接收事件後必須改變......在方法調用中添加object-id ......如果以後呢改變模型的設計或查看編輯面板的一個區域的方式導致在面板的另一部分中顯示的模型的變化 - 再次發生的變化...等等。此外,如果您按照描述的方式進行操作,那麼您將與模型和視圖的分離打破,這絕不是一個好主意。

如果您想保持簡單,請保持原樣。編寫複雜代碼的唯一原因是在運行時期間結果很糟糕,我認爲你不會那樣做。

相關問題