java Mediator 中介者模式

GOF给中介者模式下的定义是:用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地相互引用,从而使其耦合松散,而且可以独立地改变它们之间的交互。简单点来说,将原来两个直接引用或者依赖的对象拆开,在中间加入一个“中介”对象,使得两头的对象分别和“中介”对象引用或者依赖。

当然并不是所有的对象都需要加入“中介”对象。如果对象之间的关系原本一目了然,中介对象的加入便是“画蛇添足”。
中介者模式也叫调停模式,举一个例子,一项目工作需要轮翻工作,需要一个管理者(中介)统一调度,由管理者(中介)统一发布工作命令,不能由工人之间相互发布指令

public  class Workman {
    private String name;
    private Mediator mediator;

    //构造函数必把把中介者注入
    public Workman(String name,Mediator mediator){
      this.name=name;
      this.mediator=mediator;
    }
   //业务动作,相互通信息动作
    public void getOrder(String orders){
        System.out.println( this.name + "," + orders);
    }

}

   中介者
public class Mediator {
//提供参与者list,把参与通信的对象注册进来,注册动作也可放进参与者对象当中

    private List<Workman> works= new ArrayList<Workman>();

    public void add(Workman workman){
       works.add(workman);
    }

    public void clear(){
       works.clear();
    }
  //统一通信动作通过中介
    public void order(String orders){
        for(Workman m: works){
           m.getOrder(orders);
        }
    }

}

public class Client {
    public static void main(String[] agrs){
        Mediator mediator = new Mediator();

        Workman trac = new Workman("wesen",mediator);
        Workman mali = new Workman("mali",mediator);
        Workman keta = new Workman("kata",mediator);
        Workman kobe = new Workman("koti",mediator);

        mediator.add(trac);
        mediator.add(mali);
        mediator.order("have a rest!");
        mediator.clear();

        mediator.add(keta);
        mediator.add(kobe);
        mediator.order("keep working!");
        mediator.clear();
    }
}
//output
wesen,have a rest!
mali,have a rest!
kata,keep working!
koti,keep working!

如果参与者是不同对象,可以把参与者先抽象一个公类抽象类,大多数情况中介者没必然要抽象类。
由于中介者模式在定义上比较松散,在结构上和观察者模式、命令模式十分相像;而应用目的又与结构模式“门面模式”有些相似。

  在结构上,中介者模式与观察者模式、命令模式都添加了中间对象——只是中介者去掉了后两者在行为上的方向。因此中介者的应用可以仿照后两者的例子去写。但是观察者模式、命令模式中的观察者、命令都是被客户所知的,具体哪个观察者、命令的应用都是由客户来指定的;而大多中介者角色对于客户程序却是透明的。当然造成这种区别的原因是由于它们要达到的目的不同。

  从目的上看,中介者模式与观察者模式、命令模式便没有了任何关系,倒是与前面讲过的门面模式有些相似。

  但是门面模式是介于客户程序与子系统之间的,而中介者模式是介于子系统与子系统之间的。这也注定了它们有很大的区别:门面模式是将原有的复杂逻辑提取到一个统一的接口,简化客户对逻辑的使用。它是被客户所感知的,而原有的复杂逻辑则被隐藏了起来。而中介者模式的加入并没有改变客户原有的使用习惯,它是隐藏在原有逻辑后面的,使得代码逻辑更加清晰可用。

  前面已经陆陆续续的将中介者模式的特点写了出来。这里再总结一下。使用中介者模式最大的好处就是将对象解耦。这带来了一系列的系统结构改善:提高了原有系统的可读性、简化原有系统的通信协议——将原有的多对多变为一对多、提高了代码的可复用性……

  但是中介者角色集中了太多的责任,所有有关的同事对象都要由它来控制。这不由得让我想起了简单工厂模式,但是由于中介者模式的特殊性——与业务逻辑密切相关,不能采用类似工厂方法模式的解决方法。因此建议在使用中介者模式的时候注意控制中介者角色的大小。

  讨论了这么多关于中介者模式的特点。可以总结出中介者模式的使用时机:一组对象以定义良好但是复杂的方式进行通信,产生了混乱的依赖关系,也导致对象难以复用。

  四、总结

  中介者模式很容易在系统中应用,也很容易在系统中误用。当系统出现了“多对多”交互复杂的对象群,不要急于使用中介者模式,而要先反思你的系统在设计上是不是合理。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值