匂いの瞬間があり、クラスがObservableでもObserverでもOKならば、私はここに投稿すると思った。クラスは観察可能でオブザーバーはOKですか？
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に同意していますが、クラスがあまりにも多すぎる可能性があるため、コードの匂いであることがわかりました。
長い間、オブジェクトは他のオブジェクトのイベントを観察し、他のオブジェクトによって観察されている間は大丈夫です。しかし、オブジェクトがおそらくそれ自体を観察する場合、本当に変わったがあります。
多分、いくつかのコードは、デザインパターンが奇妙な方法で使用されたかどうかを理解するのに役立ちます。
これは、イベントベースのシステムがフィルタを実装する方法の1つです。もう1つは、Javaではロールの1つに内部クラスがありますが、フィルタに異なるロールを持つ複数のオブザーバがある場合は、より一般的です。だから、あなたはそれが別の役割に終わるかもしれないと思うなら、あなたは現在あなたが気づいている役割のためのアクセッサーを持っていてほしいかもしれませんが、おそらくYAGNIであり、後で追加することができます。
いいです:-)。クラスが他のクラスイベントにサブスクライブし、独自のイベントを発生させることができればOKです。確かに間違ったことをすることができますが、他のクラスを探して観察できるクラスのコンセプトは大丈夫です。
悪いです。 bは、aと通知を確認します。
だから、a.setValue（...） と何かが起きるというコードがあります。
今考えてみましょう： その代わりにコードの部分は： a.setValue（...）; c.doSomething（...）;
もちろん、このコードではaとcについて知っている必要がありますが、少なくとも には魔法はありません。すべてが日の下にある。 OOの中に隠れて 情報は、のsetValue（...）内のコードのためにあなたがの変形に迷うことがあります。2.
乾杯、 L.
を掛けオブザーバー/観測可能なパターンで なしです出版社 - 購読者パターンはイベントチャネルで、POSA本で明確に参照されています。
"この変更では、イベントチャネルが作成され、パブリッシャとそのサブスクライバの間に配置されます。購読者、購読者には出版社として表示されます。 （p。341）
ありがとうございました。このシナリオでは再送信ではありません。 – JamesC