设计原则与模式009 中介者模式

中介者模式:名如其义:其核心设计原则是迪米勒法则;通过中介者降低彼此模型之间的沟通

1产生场景

中介者模式场景介绍:
    假设有一个进销存模型，进货是根据销售情况决定，同时进货会影响库存;
最开始的流程伪代码涉及如下实体如下
Stock[库存]
Saler[销售]
Buyer[采购]


比如销售:
saler.sale(int num){
  if (!Stock.ok){ // 库存不够
    Stock.add(Buyer.buySome());
  }

     this.saleNum(num);
     Stock.reduce(num);

}
      
这段代码可以看出，销售需要同时和库存和采购打交道;复杂的业务销售需要和更多的领域打交道，不符合迪米勒法则

我们通过中介者去将帮助解决领域交互的问题，从而保障业务的干净清晰;
这就是中介者模式的产生场景

 

如果稍加扩展，业务场景更加复杂

那么引入中介者之后，其模型如下

通过中介者进行交流，每个模型只关注自身的业务，不属于自身的业务丢给中介者，从而降低了耦合度;

 

 

2中介者模式的定义

用一个中介对象封装一系列对象的交互，中介者使各对象不需要显示的交互，从而使耦合松散，而且可以独立的改变他们之间的交互;

UML图如下

每一个同事具有两种方法/行为，一为自发行为，二为依赖中介者的中介行为;

中介者
@Data
AbstartMediator{


Colleague co1;

Colleague co2;

public void abstract mediatorMethod();




}


具体中介者

@Data
Mediator{




public void mediatorMethod(){
 co1.do();
 co2.do();
}

}

同事

Colleague{
AbstartMediator mediator;
Colleague(AbstartMediator abstartMediator){
   this.mediator= abstartMediator;
}




具体同事

ColleagueObject1 extends Colleague{
   void selfMethod(){
       // 自身行为
   }
   void do(){
   
   }

   void depMethod(){
       // 依赖行为
        System.out,println("----");
        mediator.mediatorMethod();
   }



}



调用
AbstartMediator mediator = new Mediator（）;

Colleague co1 = new ColleagueObject1 (mediator );
Colleague co2 = new ColleagueObject2 (mediator );
mediator .setCo1(co1);
mediator .setCo1(co2);

// 执行依赖方法 以上对依赖类的调用交给中介者
co1.depMethod(); 

优缺点: 

1 将蜘蛛网依赖改造成星形依赖降低依赖复杂度

2 优点降低类之间的依赖，将一对多的依赖改变成1对1 的依赖

1 缺点:中介者自身会随着依赖的复杂而变得复杂，难以维护

 

适用场景:类与类之间存在依赖本身就是合理，所以中介者模式最适合的是解决复杂的蜘蛛网依赖关系，从而降低耦合

 

个人感悟:

在一个实际复杂的业务场景中，存在多个依赖类，存在多个依赖流程，实际上可以根据多个业务流程建立多个中介者模式;从而通过多个业务流程建立多个中介者的拆分来降低中介者自身的复杂，保障代码的可读性