设计模式(八) 中介者模式及MVVM

92

一、基本概念:

1、定义

用一个中介对象封装一系列的对象交互,中介者使各对象不需要直接相关作用,从而使其松耦合,中介对象可以独立的改变他们之间的交互

2、类图

image.png

  • Mediator:抽象中介者,定义接口和方法,用于各个同事角色的通信

  • ConcreteMediator:具体中介者,实现了各个同事角色的具体通信的方式

  • Colleague:同事角色,每个同事角色都知道中介者,需要跟其他同事通信时,可以通过中介者角色协作。方法分为两种,一为处理自身的行为,二为改变其他对象的行为(通过中介者进行)

3、使用场景

适用于多个对象之间耦合紧密的情况,类图出现网状引用关系时可以考虑使用中介者模式,一般是大于2个对象,并且对象之间有引用关系。比例MVP模式,Presenter可以作为一个中介者,减少了View层和Model层的耦合关系。

4、优点

同事类只依赖中介者,减少了类的依赖,降低了类之间的耦合

5、缺点:

中介者逻辑复杂,同事类越多,中介者的逻辑就越复杂

二、实例

1、抽象同事类

public abstract class Colleague {
  protected Mediator mediator;

  public Colleague(Mediator _mediator) {
    this.mediator = _mediator;
  }
}

2、具体同事类

class ConcreteColleague1 extends Colleague {
  public ConcreteColleague1(Mediator _mediator) {
    super(_mediator);
  }

  public void selfMethod1() {
    //处理自己的业务
    //需要委托给中介者处理的业务
    mediator.doSomething1();
  }

  public void selfMethod3() {

  }
}
class ConcreteColleague2 extends Colleague {
  public ConcreteColleague2(Mediator _mediator) {
    super(_mediator);
  }

  public void selfMethod2() {
    //处理自己的业务
    //需要委托给中介者处理的业务
    mediator.doSomething2();
  }

  public void selfMethod4() {

  }
}

3、抽象中介者

public abstract class Mediator {

  protected ConcreteColleague1 c1;
  protected ConcreteColleague2 c2;

  public ConcreteColleague1 getC1() {
    return c1;
  }

  public void setC1(ConcreteColleague1 c1) {
    this.c1 = c1;
  }

  public ConcreteColleague2 getC2() {
    return c2;
  }

  public void setC2(ConcreteColleague2 c2) {
    this.c2 = c2;
  }

  public abstract void doSomething1();

  public abstract void doSomething2();
}

4、具体中介者

public class ConcreteMediator extends Mediator {

  @Override
  public void doSomething1() {
    //调用其他同事类的处理逻辑
    c2.selfMethod4();
  }

  public void doSomething2() {
    c1.selfMethod3();
  }
}

二、MVC、MVP、MVVM

Controller、Presenter、ViewModel都可以作为中介者,协调View和Model的通信,避免了两者的耦合

1、MVC

image.png

  • Controller:Activity/Fragment
  • View层:xml文件和Activity部分功能
  • Model层:管理业务数据逻辑

问题: Activity/Framgent除了业务逻辑,还需要处理UI。造成Activity里包括了视图和业务的代码,分离程度不够。

2、MVP

image.png

  • Model层:管理数据存取,一般是网络或者数据库
  • View层:视图处理,一般是Activity或Fragment、xml文件
  • Presenter层:作为View和Mdoel沟通的桥梁,处理业务逻辑

优点:
通过接口进行通信,降低耦合、逻辑分层。

缺点:

  • 协议接口类容易膨胀,不易维护
  • 内存泄露风险: Presenter持有View层引用,关闭View层时Model层如有耗时操作,可能有内存泄露的风险

3、MVVM

image.png

  • Model:数据存取
  • View:视图处理,一般是Activity或Fragment
  • ViewModel:业务逻辑处理

常用组件:

  • Lifecycle:生命周期状态回调
  • LiveData:可观察的数据存储类
  • databinding:可自动同步的UI和data
  • ViewModel:业务逻辑的管理和liveData的维护

优点:

  • ViewModel不需要直接向View回调,通过观察者模式监听数据变化
  • 可以通过DataBinding进行UI动态更新
  • 无过多接口回调、生命周期的管理、数据更新的监听

缺点:

  • LiveData膨胀,需要定义多个LiveData。缺少唯一的数据源

汇总:设计模式总结