I. 概要
Mediator パターンは、一連のオブジェクト間の相互作用をカプセル化する Mediator オブジェクトを定義します。Mediator はオブジェクト間の明示的な相互参照を不要にし、結果として結合を減らし、オブジェクト間の相互作用の振る舞いを独立に変更することを可能にします。Mediator パターンは振る舞いのパターンです。その主な目的は、複数のオブジェクトやクラス間の通信の複雑さを軽減することです。
仲介モデルとは、不動産業者のように住宅の売買のプラットフォームを提供することで、売り手は仲介業者に住宅を売りに出し、買い手は仲介業者に買いに行くことができ、売り手と買い手は仲介業者を通してやり取りをするため、両者間の参照に関係する必要がなく、買い手と売り手を切り離すことができます。
仲介モデルは、主にこの4つの役割から構成されています：
- 抽象的な仲介役：各協力オブジェクトとの通信のための抽象クラスまたはインターフェースとして機能します。
- ConcreteMediator (具象 Mediator)：抽象 Mediator のメソッドを実装し、具象ロジッ クを実装します。
- Colleague (abstract collaborator/colleague): コラボレーターに共通するメソッドを抽象化し、サブクラスが通信できる抽象仲介クラスへの参照を保持します。
- 特定の共同作業者/同僚：Colleagueのメソッドを実装し、各共同作業オブジェクトは、他の共同作業オブジェクトと通信する必要がある場合、最初に仲介者と通信します。
以下に、売買のためにエージェントに住宅をリストアップした例を示します。
II.
まず、抽象的な仲介業者がいて、家を売る方法は一つしかありません。
/**
* 抽象仲介
*/
public interface Mediator {
//
void sale(Seller agent, int area, int price);
}
次に、抽象的なコラボレーター/コレゴリーグがあり、クラス名はSeller売り手によって示され、これは少し理解しやすく、仲介者への参照を保持します。
/**
* 抽象コラボレーター-
*/
public abstract class Seller {
protected static final String TAG = "XXX";
protected String name;
protected Mediator mediator;
public Seller(String name, Mediator mediator){
this.name = name;
this.mediator = mediator;
}
public void sellHouse(int area, int price){
mediator.sale(this, area, price);
}
//メリットを示す
public abstract void showAdvantage();
}
さらに具体的な同僚クラスがあり、ここでは3つの同僚クラスが家を売るために定義され、この家の利点を示す抽象メソッドshowAdvantage()で独自のロジックを実装します。
/**
* 特定の協力者 - 張三
*/
public class tanakaSan extends Seller {
public tanakaSan(String name, Mediator mediator) {
super(name, mediator);
}
@Override
public void showAdvantage() {
Log.e(TAG, "この家は学区の家だ。~~~");
}
}
/**
* 特定の協力者 - Li Si
*/
public class LiSi extends Seller {
public LiSi(String name, Mediator mediator) {
super(name, mediator);
}
@Override
public void showAdvantage() {
Log.e(TAG, "この家は地下鉄の入り口に近い。~~~");
}
}
/**
* 具体的な協力者 - Wang Wu
*/
public class WangWu extends Seller {
public WangWu(String name, Mediator mediator) {
super(name, mediator);
}
@Override
public void showAdvantage() {
Log.e(TAG, "この家にはスーパーや病院などの周辺サポートがある。~~~");
}
}
具体的な仲介者は、ご覧のように、すべての売り手を保持し、売り手間の直接のコミュニケーションはありませんが、仲介者を介して通信し、売買の具体的なロジックをSALEという抽象的な方法で実行します。
/**
* 具体的な仲介者
*/
public class ConcreteMediator implements Mediator {
private static final String TAG = "XXX";
private tanakaSan tanakaSan;
private LiSi liSi;
private WangWu wangWu;
public void setZhangSan(tanakaSan tanakaSan) {
this.tanakaSan = tanakaSan;
}
public void setLiSi(LiSi liSi) {
this.liSi = liSi;
}
public void setWangWu(WangWu wangWu) {
this.wangWu = wangWu;
}
@Override
public void sale(Seller agent, int area, int price) {
Log.e(TAG, " " + agent.name + "Androidの中間のパターンである：" + area + "Pingback: 引用：" + price + " ");
if(agent == tanakaSan){
tanakaSan.showAdvantage();
}else if(agent == liSi){
liSi.showAdvantage();
}else{
wangWu.showAdvantage();
}
}
}
最後に、テストを行いました。まず、特定の仲介オブジェクトと3つの売り手オブジェクトを作成し、売り手オブジェクトを仲介オブジェクトに設定しました。印刷結果を以下に示します。
ConcreteMediator concreteHouse = new ConcreteMediator();
tanakaSan tanakaSan = new tanakaSan(" ",concreteHouse);
LiSi liSi = new LiSi(" ",concreteHouse);
WangWu wangWu = new WangWu(" ",concreteHouse);
concreteHouse.setZhangSan(tanakaSan);
concreteHouse.setLiSi(liSi);
concreteHouse.setWangWu(wangWu);
tanakaSan.sellHouse();
Log.e(TAG, "----------------------------");
liSi.sellHouse();
Log.e(TAG, "----------------------------");
wangWu.sellHouse();
まとめ
インターミディエイト・パターンを使うことには、次のような利点があります：
- 仲介パターンは、オブジェクト間の相互作用を簡素化し、それは1対多の相互作用の代わりに、多対多の相互作用の元の同僚クラスの仲介と同僚を使用し、1対多の関係を理解し、維持し、拡張する方が簡単です、元のスター構造の相対的な順序のメッシュ構造を理解するのは難しい；
- 個々の同僚クラス・オブジェクトは切り離すことができ、個々の同僚クラスと仲介者は独立して変更および再利用できます；
もちろん、コードの中に同僚クラスが多すぎると、仲介クラスが非常に複雑になり、システムのメンテナンスが難しくなるという欠点もあります。
githubアドレス：github.com/leewell5717...
