メディエーターデザインパターンの同僚について

Question

私は仲介者のパターンの目的は、各同僚が互いに知り合う必要がないということです。すべての同僚はメディエーターについて知っているだけです。

デザインパターンは特定の言語用ではありませんが、私の質問はJava固有のものです。

私はスーパークラスにサブクラスのフィールドを入れたいのですが、Javaでいくつかの問題があるでしょう：Javaでは

• 、インターフェース内のすべてのフィールドがpublic static finalあり、それはまたに良い習慣ではありませんそのようなフィールドを使用します。それは最終的なものであるため、私はインターフェイス同僚に仲介者に参照を置く場合（Why）

• は、その後、それぞれの具体的な同僚は、実行時にその仲介者を変更することはできません。

  interface Colleague { 
      Mediator mediator; // Which is public static final 
  } 
  

  そうでプログラム、

  { 
      // ... 
      colleague.changeMediator(newMediator); // this is impossible. 
      // ... 
  } 
  

  。

• 以下の構造のように、同僚は代わりに抽象クラスです。具体的な同僚がすでに他のクラスを継承している可能性があり、Javaで複数の継承が許可されていないため、このパターンは役に立ちません。

  Fooは、すでにBarを継承しているため、具体的な同僚になることはできません。

  public class Foo extends Bar, Colleague { // this is impossible. 
      // ... 
  } 
  

インタフェース同僚に仲介者から参照を入れる方法がない場合は、私が考えた解決策は以下のとおりです。this exampleとして

1. 、参照を削除。メディエータへの参照を保持する必要はないと仮定する。 （これは何か問題を引き起こしますか？）

2. 各コンクリートの同僚の参照を定義するだけです。 （ただし、これはコードの繰り返しを意味します）

3. design-patterns-stories.comの例として、同僚を抽象化し、誰も同僚を拡張しないという事実を受け入れるようにしてください。

（design-patterns-stories.comから）Mediatorパターンの構造：

Answer 1

あなたがすることができる2つのことがあります。

• ので、あなたがpublic class Colleague<? extends Mediator>

• を持っていると思いますMediatorを拡張している一般的なことColleagueを定義するパターンがそれを求めていてもMediatorから継承しません。それを引数として渡し、通知を呼び出します。