有一個代碼氣味的時刻，並不能決定如果它可以爲一個類是可觀察的，也是一個觀察者，所以想我會在這裏發表。可以觀察一個班級和觀察員嗎？
class ObservableAndObserver extends Observable implements Observer {
// Class is ofcourse registering and receving notifcations on different events
// effectly actving as a middle man.
// Is this a pattern in itself? 'middleman-pattern' ??
}
想法？打破SRP？
這在技術上是可以的，但你應該檢查你是不是簡單地重新發送收到的通知。如果這個類正在觀察class1，然後被class2觀察到，請嘗試讓這個類觀察class1。
我看不到任何理由。但具體的 例子將是有用的。更好的是你已經實現的真正的代碼，我們可以批評。
雖然我同意Neil，但我可以看到它是一種代碼味道，因爲這個類可能做得太多了。
只要對象觀察其他對象的事件，並且其他對象可以觀察到它就可以。但是，如果對象觀察到自己可能有什麼真的很奇怪。
也許一些代碼將有助於瞭解設計模式是否以奇怪的方式使用。
這是許多基於事件的系統實現過濾器的一種方式。另一方面，在Java中，其中一個角色具有內部類，但如果過濾器具有多個角色不同的觀察者，則更爲常見。所以，如果你認爲它可能以不同的角色結束，你可能希望它有一個你目前想要的角色的訪問者getObserver() { return this; }，但這可能是一個YAGNI，可以稍後添加。
沒關係:-)。如果班級訂閱其他班級活動並且可以舉辦自己的活動，那就沒問題。當然，你可以做錯，但類尋找其他類的觀念是可以觀察的。
它是邪惡的。 b觀察a並通知c。
所以有一段代碼說a.setValue（...） 和c中的某些事情發生。
現在想想這個： 那段代碼反而應該說： a.setValue（...）; c.doSomething（...）;
當然這段代碼現在必須知道a和c，但至少有 沒有魔法。一切都在陽光下。 信息隱藏在面向對象是乘以2
乾杯的setValue代碼（...） 沒有觀察者/可觀察的模式， L.
你可能會誤入的一個變種所謂事件通道發行者 - 訂閱模式，這是在POSA書中明確提到：
「在這種變化情況下，創建並放置出版商和用戶之間的事件通道給出版商，事件通道出現。訂閱者，而訂閱者則表現爲發佈者「。 （第341頁）
謝謝。在這種情況下，這不是重新傳輸。 – JamesC 2009-08-20 17:04:30