23設計モード20：Java仲介モデル
定義：メディエーターオブジェクトとの一連のオブジェクトの相互作用をカプセル化します。メディエーターは、各オブジェクトを表示せずに対話させ、それにより結合を緩め、それらの間の相互作用を独立して変更します。
タイプ：行動パターン
クラス図：
中間モデルの構造
中間モードは、メディエーターモードとも呼ばれます。クラス図から、3つの部分に分かれています。
抽象メディエーター：同僚のクラスオブジェクトとメディエーターオブジェクトの間のインターフェイスを定義し、各同僚クラス間の通信に使用されます。一般に、1つまたは複数の抽象イベントメソッドが含まれ、サブクラスによって実装されます。
中間実装クラス：抽象的なメディエーターから継承され、抽象メディエーターで定義されたイベント方法を実装します。ある同僚クラスからメッセージを受信し、メッセージを通して他の同時クラスに影響を与えます。
同僚のクラス：オブジェクトが他のオブジェクトに影響を与え、他のオブジェクトの影響を受ける場合、これらの2つのオブジェクトは同僚クラスと呼ばれます。クラス図には、同僚のクラスが1つしかありません。これは実際には現実の省略です。実際のアプリケーションでは、同僚のクラスは一般に複数で構成されており、互いに影響を与え、依存しています。同僚が多いほど、関係が複雑になります。さらに、同僚のクラスは、同じ抽象クラスを継承する一連の実装として表現することもできます。仲介モデルでは、メッセージは同僚間の仲介者を介して送信する必要があります。
なぜ中間モデルを使用するのか
一般的に言えば、同僚のクラス間の関係は比較的複雑です。複数の同僚のクラスが相関している場合、その関係は複雑なメッシュ構造として表示されます。これは、過剰に結合されたアーキテクチャです。つまり、クラスの再利用を助長せず、安定していません。たとえば、下の図には、6つの同僚のようなオブジェクトがあります。オブジェクト1が変更されると、4つのオブジェクトが影響を受けます。オブジェクト2が変更されると、5つのオブジェクトが影響を受けます。言い換えれば、同僚間の直接的な相関の設計は良くありません。
仲介モデルが導入された場合、同僚のクラス間の関係は星構造になります。図から、どのクラスの変更がクラス自体と仲介者にのみ影響し、システムの結合が減少することがわかります。優れたデザインは、このクラスのすべてのオブジェクト関連処理ロジックを間違いなくカプセル化することはありませんが、特別なクラスを使用して、あなたに属さない動作を管理します。
例を使用して、同僚のクラスが何であるかを説明しましょう。クラスAとBが2つあり、それぞれに数字があります。クラスBの数値がクラスAの数の100倍であることを確認する必要があります。つまり、数字を100に掛けてクラスBに割り当て、クラスBを変更するとき、クラスAに属します。コードは次のとおりです。
Abstract Class AbstractColleague {protected int number; public int getNumber（）{return number; } public void setnumber（int number）{this.number = number; } //要約方法、数字を変更するときに関連するオブジェクトを同時に変更しますabstract void setnumber（int number、abstractcolleague coll）; } class colleagueaはabstractcolleagueを拡張します{public void setnumber（int number、abstractcolleague coll）{this.number = number; coll.setnumber（number*100）; }} class colleaguebはabstractcolleagueを拡張します{public void setnumber（int number、abstractcolleague coll）{this.number = number; coll.setnumber（number/100）; }} public class client {public static void main（string [] args）{abstractColleague colla = new Colleaguea（）; AbstractColleague collb = new Colleaguegb（）; System.out.println（ "===================================================== ============================================================================= ============================================================================= ============================================================================ ============================================================================= ============================================================================= ============================================================================= ============================================================================ system.out.println（ "collbの数値：+collb.getnumber（））;上記のコードでは、クラスAとBは直接的な関連性を通じて関連しています。仲介モデルを使用したい場合、クラスAとBを直接関連付けることはできません。彼らは、関連性の目的を達成するために仲介者を使用する必要があります。
Abstract Class AbstractColleague {protected int number; public int getNumber（）{return number; } public void setnumber（int number）{this.number = number; } //ここのパラメーターはもはや同僚ではなく、中間公開抽象void setnumber（int number、abstractmediator am）であることに注意してください。 } class colleagueaはabstractcolleagueを拡張します{public void setnumber（int number、abstractmediator am）{this.number = number; am.aaffectb（）; }} class colleaguebはabstractcolleagueを拡張します{@override public void setnumber（int number、abstractmediator am）{this.number = number; am.baffecta（）; }} Abstract Class AbstractMediator {Protected AbstractColleague A;保護されたAbstractColleague B; public abstractMediator（AbstractColleague A、AbstractColleague B）{a = a; b = b; } public Abstract void aaffectb（）; public abstract void baffecta（）; }クラスメディエーターはAbstractMediatorを拡張します{Public Mediator（AbstractColleague A、AbstractColleague B）{Super（a、b）; } // Aの影響を処理します。 B.SetNumber（番号*100）; } // bの衝撃をpublic void baffecta（）{int number = b.getnumber（）; a.setNumber（number/100）; }} public class client {public static void main（string [] args）{abstractColleague colla = new Colleaguea（）; AbstractColleague collb = new Colleaguegb（）; AbstractMediator AM = New Mediator（Colla、Collb）; System.out.println（ "==================================================================== A =================================================================================================================================== =========================================================================================================================== =========================================================================================================================== ================================================================================================================================= System.out.println（ "Collaの数値は次のとおりですB ========================================================================================================================= ====================================================================================================================== ===================================================================================================================== ====================================================================================================================== system.out.println（ "collbの数値は次のとおりです。コードは比較的長いですが、まだ理解するのは比較的簡単です。実際、元々オブジェクト関係を調停クラスに処理し、この調停クラスを通じてオブジェクト間の関係を処理するコードを再パッケージ化することです。
仲介モデルの利点
1.仲介モデルの適切な使用は、同僚のクラス間の過度の結合を回避でき、各同僚のクラスを比較的独立して使用できるようにします。
2.メディエーターパターンを使用すると、オブジェクト間の1対多数の関係を1対1の関係に変換し、オブジェクト間の関係を理解し、維持しやすくします。
3.中間モデルを使用すると、オブジェクトの動作とコラボレーションを抽象化し、オブジェクト間の相互作用をより柔軟に処理できます。
適用可能なシナリオ
オブジェクト指向プログラミングでは、クラスは必然的に他のクラスに依存し、完全に独立したクラスは無意味です。また、クラスが複数のクラスに同時に依存することも非常に一般的です。このような状況が存在するため、1対多依存性に合理性があることを意味します。メディエーターパターンを適切に使用すると、元々乱雑なオブジェクト関係が明確になりますが、乱用されている場合、悪影響をもたらす可能性があります。一般的に言えば、メディエーターモデルは、メッシュ構造がある同僚クラス間の関係についてのみ考慮されます。メッシュ構造を星構造に変換して、同僚間の関係をより明確にすることができます。
中間モデルは、比較的一般的なモデルであり、比較的乱用されやすいモデルです。ほとんどの場合、同僚のクラス間の関係は、混oticとしたメッシュ構造とは複雑ではありません。したがって、ほとんどの場合、同僚クラス内のオブジェクト間の依存関係をカプセル化することは問題ありません。また、仲介モデルを導入する必要はありません。仲介モデルの乱用は、物事をより複雑にするだけです。
上記はこの記事のすべての内容です。みんなの学習に役立つことを願っています。誰もがwulin.comをもっとサポートすることを願っています。