コードのにおいがする瞬間があり、クラスが Observable であり Observer でもよいかどうか判断できなかったので、ここに投稿すると思いました。
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 を監視させてみてください。
そうしない理由がわかりません。ただし、具体的な例は役に立ちます。さらに良いのは、あなたが既に実装した実際のコードで、私たちが批評できるものです。
大丈夫です ：-）。クラスが他のクラス イベントをサブスクライブし、独自のイベントを発生させることができれば問題ありません。確かに間違っている可能性がありますが、他のクラスを探して観察可能にするというクラスの概念は問題ありません。
それは悪です。bはaを観察し、cに通知します。
したがって、a.setValue（...）というコードがあり、cで何かが発生します。
今これを考えてください：代わりにそのコードの部分は言うべきでした：a.setValue（...）; c.doSomething（...）;
もちろん、そのコードはaとcについて知っている必要がありますが、少なくとも魔法はありません。すべてが太陽の下にあります。ooに隠されている情報は、オブザーバー/オブザーバブルパターンのsetValue（...）noに2を掛けたコード用です。
乾杯、L。
POSA ブックで明確に参照されているEvent Channelと呼ばれる Publisher-Subscriber パターンのバリアントに迷い込んでいる可能性があります。
「このバリアントでは、イベント チャネルが作成され、パブリッシャーとそのサブスクライバーの間に配置されます。パブリッシャーにはイベント チャネルがサブスクライバーとして表示され、サブスクライバーにはパブリッシャーとして表示されます」. (p.341)
While I agree with Neil, I could see it being a code smell because the class could be doing too much.
これは、多くのイベント ベースのシステムがフィルターを実装する方法の 1 つです。もう 1 つは、Java ではロールの 1 つに内部クラスを持ちますが、フィルターに異なるロールを持つ複数のオブザーバーがある場合は、より一般的です。そのため、最終的に別のロールになる可能性があると思われる場合は、現在考えているロールのアクセサーが必要になる場合がありますがgetObserver() { return this; }、それはおそらく YAGNI であり、後で追加できます。
オブジェクトが他のオブジェクトのイベントを観察し、他のオブジェクトによって観察される限り、問題ありません。しかし、オブジェクトがそれ自体を観察する場合、おそらく何か本当に奇妙なことがあります。
設計パターンが奇妙な方法で使用されているかどうかを理解するのに役立つコードがあるかもしれません。