1. 動機
- ソフトウェア構築の過程では、複数のオブジェクトが相互作用することが多く、オブジェクト間で複雑な参照関係が維持されることがよくありますが、要件が変更されると、この直接の参照関係も常に変化することになります。
- この場合、「中間オブジェクト」を使用してオブジェクト間の関係を管理し、相互作用するオブジェクト間の緊密に結合された参照関係を回避し、変更に強く耐えることができます。
例：
インターフェイスには多くのコントロールがあります。現時点では、通常、インターフェイス コントロールの状態を変更するときは、その背後にデータ DataModel がある可能性があり、それに応じてそれを変更したいと考えます。同様に、DataModel が変更された場合も同様です。 、あなたのインターフェースも変更をフォローすることを望んでいます。この状況は、双方向の直接依存関係につながります。つまり、インターフェイス要素は DadaModel オブジェクトを参照する必要があり、データ オブジェクトもインターフェイス要素を参照する必要がある場合があります。これは明らかに適切ではありません。たとえば、インターフェイス要素が後で置き換えられる場合、改造費用は非常に高額です。
2. スキーマ定義
中間オブジェクトを使用して、一連のオブジェクトの対話をカプセル化 (変更をカプセル化) します。メディエーターは、オブジェクトが相互に明示的に参照する必要がないようにし (コンパイル時の依存関係 -> 実行時の依存関係)、オブジェクトを疎結合にし (変更を管理し)、オブジェクトの相互作用を独立して変更できます。
----《デザインパターン》GOF
3. 構造
上の図では、ConcreteColleague1 と ConcreteColleague2 は直接依存していますが、上の図の同僚の間に依存関係はありません。これらはすべて Mediator に依存しています。次に、Mediator は内部的に Colleague に依存しているため、Colleague と Mediartor は直接双方向です。依存。
しかし実際には、先ほどのコンポーネントとDataBaseのように、ConcreteColleague1とConcreteColleague2は上図の継承関係にないことが多いです。
よりわかりやすいグラフ表現:
たとえば、上記の依存関係では、上記の構造図の数字で表されるノードはすべて Colleague であり、次のように変更されます。
一部のネチズンは、Mは少し「財産」に似ていて、非常にイメージが強いと言いました！！
このモードは Facade モードに似ています。どちらも分離のための新しいクラスを提案します。Facade はシステム外部とシステム内の分離を解決し、仲介はシステム内のさまざまなクラスの分離を解決します。
4. 要点のまとめ
- Mediator モードでは、複数のオブジェクト間の複雑な関係を切り離し、複数のオブジェクト間の制御ロジックを一元管理し、「複数のオブジェクトが相互に関連付けられている」から「複数のオブジェクトがメディエーターに関連付けられている」に変更し、システムを簡素化します。 。
- 制御ロジックが複雑なため、Mediator 具象オブジェクトの実装は非常に複雑になる場合があります。この時点で、Mediator オブジェクトを分解できます。
- ファサード モードでは、システム間の (一方向) オブジェクトの関連付けが分離され、メディエーター モードでは、システム内のオブジェクト間の (双方向) の関連付けが分離されます。