スマートホームプロジェクト:
1) スマートホームには、目覚まし時計、コーヒーメーカー、テレビ、カーテンなどのさまざまなデバイスが含まれます。
２）飼い主がテレビを見たいと思ったとき、アラームが鳴る→コーヒーメーカーがコーヒーを淹れ始める→自動的にカーテンが降りる→といったように、すべての機器が連携してテレビを見るための準備を自動的に完了させることができます。テレビが再生を開始します
従来の問題分析方法
1) 各電気オブジェクトに複数の状態変化がある場合、それらの間の呼び出し関係はより複雑になります。
2) それぞれの電気物体は互いに接続されており、あなたの中に私がいて、私の中にあなたがいます。これは疎結合を助長しません。
3) 電気物体間で受け渡されるメッセージ（パラメータ）は混同されやすい
4) システムが新しい電気オブジェクトを追加する場合、または実行プロセスが変更される場合、コードの保守性と拡張性は理想的ではありません 中間モデルを検討する
基本的な紹介
1) メディエーター パターン。メディエーター オブジェクトを使用して一連のオブジェクト インタラクションをカプセル化します。メディエーターは、相互への明示的な参照の必要性を排除することでオブジェクトを疎結合にし、それらの相互作用は独立して変更できます。
2) 中間モードは動作モードであるため、コードの保守が容易になります。
3) たとえば、MVC モードでは、C (コントローラー) は M (モデル) と V (ビュー) の間の仲介者であり、フロントエンドとバックエンド間の対話の仲介者として機能します。
中間パターンの原理クラス図
原理クラス図の説明（中間モードの役割と責任）
1) Mediator は抽象仲介者であり、同僚オブジェクトから仲介オブジェクトへのインターフェイスを定義します。
2) 同僚は抽象的な同僚クラスです
3) ConcreteMediator 特定の中間オブジェクトは抽象メソッドを実装します。彼はすべての具体的な同僚クラスを知る必要があります。
コアコード:
// アラームを作成し、ConcreteMediator オブジェクトの HashMap に追加します。
Alarm アラーム = new Alarm(mediator, "alarm");
アラーム内:
//コンストラクター
public Alarm(Mediator mediator, String name) { super(mediator, name); //TODO 自動生成されたコンストラクター スタブ //Alarm 同僚オブジェクトを作成するときは、自分自身を ConcreteMediator オブジェクト [Collection] メディエーターに置きます.Register(名前, これ); }
核心はメディエータの register メソッドにあります。
@Override
public void Register(String believerName, Colleague believer) { // TODO 自動生成されたメソッド スタブ coleagueMap.put(colleagueName, 同僚);
// TODO 自動生成されたメソッド スタブ
if (同僚インスタンスオブアラーム) { interMap.put("アラーム", 同僚名); else if (CoffeeMachine の同僚インスタンス) { interMap.put("CoffeeMachine", 同僚名); } else if (テレビの同僚インスタンス) { interMap.put("テレビ", 同僚名); } else if (カーテンの同僚インスタンス) { interMap.put("カーテン", 同僚名); }
}
アラームが作動したら:
//目覚まし時計にメッセージを送信させます
。alarm.SendAlarm(0);
メディエーターのメソッドにコールバックします:
//特定のメディエーターのコア メソッド
//1. 受信したメッセージに従って対応するタスクを完了します
//2. このメソッドでは、メディエーターは特定の各同僚オブジェクトを調整してタスクを完了します
@ Override
public void GetMessage (int stateChange, String believerName) { // TODO 自動生成されたメソッド スタブ
//目覚まし時計からのメッセージを処理します
if (colleagueMap.get(colleagueName)instanceofAlarm) { if (stateChange == 0) { ((CoffeeMachine) (colleagueMap.get(interMap .get("CoffeeMachine")))) StartCoffee( ); ((TV) (colleagueMap.get(interMap.get("TV")))).StartTv(); } else if (stateChange == 1) { ((TV) (colleagueMap.get(interMap. get( "テレビ")))).StopTv(); }
else if (colleagueMap.get(colleagueName)instanceofCoffeeMachine) { ((カーテン) (colleagueMap.get(interMap.get("Curtains")))) .UpCurtains();
} else if (colleagueMap.get(colleagueName)instanceof TV) {//TV がメッセージを見つけた場合
} else if (colleagueMap.get(colleagueName)instanceofCurtains) { //メッセージがカーテンから送信された場合、ここで処理されます... }
}
メッセージをメディエーターに送信した後、メディエーターは関連する処理のために他のクラスを呼び出します。
Mediator パターンの注意事項と詳細
1) 複数のクラスが相互に結合されてネットワーク構造を形成し、中間モードを使用してネットワーク構造をスター構造に分離して分離します。
2) クラス間の依存関係を減らし、結合を減らし、Dimit 原則に準拠します。
3) 仲介者の責任が重くなり、仲介者に問題が発生すると、システム全体に影響が及びます。
4) 設計が適切でないと、中間オブジェクト自体が複雑になりすぎるため、実際の使用ではこの点に特に注意が必要です