收藏私塾在线
 

欢迎您来到私塾在线网!   

请登录! 

免费注册 


javasscc的笔记
状态: 离线
人气:515729
访问用户量:1155
笔记经验:
总积分:1958
级别:普通会员
搜索本笔记
ta的交流分类
ta的交流主题贴(196)
ta的所有交流贴(200)
ta的全部笔记
全部笔记(98)
未分类笔记(0)
研磨设计模式(94)
课程问题(0)
设计模式综合项目实战(4)
存档
2013-05(4)
2012-08(39)
2012-07(55)

2013-01-18 18:25:44
研磨设计模式 之 中介者模式(Mediator)3 ——跟着cc学设计系列
浏览(8299)|评论(1)   交流分类:Java|笔记分类: 研磨设计模式

10.3  模式讲解

10.3.1  认识中介者模式

(1)模式的功能

中介者的功能非常简单,就是封装对象之间的交互。如果一个对象的操作会引起其它相关对象的变化,或者是某个操作需要引起其它对象的后续或连带操作,而这个对象又不希望自己来处理这些关系,那么就可以找中介者,把所有的麻烦扔给它,只在需要的时候通知中介者,其它的就让中介者去处理就可以了。

       反过来,其它的对象在操作的时候,可能会引起这个对象的变化,也可以这么做。最后对象之间就完全分离了,谁都不直接跟其它对象交互,那么相互的关系,全部被集中到中介者对象里面了,所有的对象就只是跟中介者对象进行通信,相互之间不再有联系。

把所有对象之间的交互都封装在中介者当中,无形中还得到另外一个好处,就是能够集中的控制这些对象的交互关系,这样有什么变化的时候,修改起来就很方便。

(2)需要Mediator接口吗

       要回答这个问题,先要搞清楚一件事情,接口用来干什么的?对,接口是用来实现“封装隔离”的,那么封装谁?隔离谁呢?Mediator接口嘛,肯定是用来封装中介者对象的,使得使用中介者对象的客户对象跟具体的中介者实现对象分离开。

       了解了上面这些内容,回过来想想,有没有使用Mediator接口的必要,那就取决于是否会提供多个不同的中介者实现。如果中介者实现只有一个的话,而且预计中也没有需要扩展的要求,那么就可以不定义Mediator接口,让各个同事对象直接使用中介者实现对象;如果中介者实现不只一个,或者预计中有扩展的要求,那么就需要定义Mediator接口,让各个同事对象来面向中介者接口编程,而无需关心具体的中介者实现。

(3)同事关系

       在标准的中介者模式中,把使用中介者对象来交互的那些对象称为同事类,这不是乱叫的,在中介者模式中,要求这些类都要继承相同的类,也就是说,这些对象从某个角度讲是同一个类型,算是兄弟对象。

       正是这些兄弟对象之间的交互关系很复杂,才产生了把这些交互关系分离出去,单独做成中介者对象,这样一来,这些兄弟对象就成了中介者对象眼里的同事。

(4)同事和中介者的关系

       在中介者模式中,当一个同事对象发生了改变,需要主动通知中介者,让中介者去处理与其它同事对象相关的交互。

       这就导致了同事对象和中介者对象之间必须有关系,首先是同事对象需要知道中介者对象是谁;反过来,中介者对象也需要知道相关的同事对象,这样它才能与同事对象进行交互。也就是说中介者对象和同事对象之间是相互依赖的。

(5)如何实现同事和中介者的通信

       一个同事对象发生了改变,会通知中介者对象,中介者对象会处理与其它同事的交互,这就产生了同事对象和中介者对象的相互通信。怎么实现这种通信关系呢?

       一种实现方式是在Mediator接口中定义一个特殊的通知接口,作为一个通用的方法,让各个同事类来调用这个方法,在中介者模式结构图里画的就是这种方式。在前面示例的也是这种方式,定义了一个通用的changed方法,并且把同事对象当做参数传入,这样在中介者对象里面,就可以去获取这个同事对象的实例的数据了。

       另外一种实现方式是可以采用观察者模式,把Mediator实现成为观察者,而各个同事类实现成为Subject,这样同事类发生了改变,会通知Mediator。Mediator在接到通知过后,会与相应的同事对象进行交互。

(6)中介者模式的调用顺序示意图

中介者模式的调用顺序如图10.5所示:

 

图10.5  中介者模式的调用顺序示意图

10.3.2  广义中介者

仔细查看中介者的结构、定义和示例,会发现几个问题,使得中介者模式在实际使用的时候,变得繁琐或困难。

  • 其一:是否有必要为同事对象定义一个公共的父类?

大家都知道,Java是单继承的,为了使用中介者模式,就让这些同事对象继承一个父类,这是很不好的;再说了,这个父类目前也没有什么特别的公共功能,也就是说继承它也得不到多少好处。

在实际开发中,很多相互交互的对象本身是没有公共父类的,强行加上一个父类,会让这些对象实现起来特别别扭。

  • 其二:同事类有必要持有中介者对象吗?

同事类需要知道中介者对象,以便当它们发生改变的时候,能够通知中介者对象,但是,是否需要作为属性,并通过构造方法传入,这么强的依赖关系呢?

也可以有简单的方式去通知中介对象,比如把中介对象做成单例,直接在同事类的方法里面去调用中介者对象。

  • 其三:是否需要中介者接口?

在实际开发中,很常见的情况是不需要中介者接口的,而且中介者对象也不需要创建很多个实例,因为中介者是用来封装和处理同事对象的关系的,它一般是没有状态需要维护的,因此中介者通常可以实现成单例。

  • 其四:中介者对象是否需要持有所有的同事?

虽说中介者对象需要知道所有的同事类,这样中介者才能与它们交互。但是是否需要做为属性这么强烈的依赖关系,而且中介者对象在不同的关系维护上,可能会需要不同的同事对象的实例,因此可以在中介者处理的方法里面去创建、或者获取、或者从参数传入需要的同事对象。

  • 其五:中介者对象只是提供一个公共的方法,来接受同事对象的通知吗?

从示例就可以看出来,在公共方法里,还是要去区分到底是谁调过来,这还是简单的,还没有去区分到底是什么样的业务触发调用过来的,因为不同的业务,引起的与其它对象的交互是不一样的。

因此在实际开发中,通常会提供具体的业务通知方法,这样就不用再去判断到底是什么对象,具体是什么业务了。

       基于上面的考虑,在实际应用开发中,经常会简化中介者模式,来使开发变得简单,比如有如下的简化:

  • 通常会去掉同事对象的父类,这样可以让任意的对象,只要需要相互交互,就可以成为同事;
  • 还有通常不定义Mediator接口,把具体的中介者对象实现成为单例;
  • 另外一点就是同事对象不再持有中介者,而是在需要的时候直接获取中介者对象并调用;中介者也不再持有同事对象,而是在具体处理方法里面去创建、或者获取、或者从参数传入需要的同事对象。

       把这样经过简化、变形使用的情况称为广义中介者。

       还是来举个实际点的例子看看吧。

1:部门与人员

几乎在每个应用系统中都需要这样的功能模块:部门管理、人员管理,为了简单点演示,把模块简化成类,也就是有一个部门类Dep和人员类User。

       首先想想部门类Dep和人员类User之间是什么关系,一对一?一对多?还是多对多?

       可能在不同的系统里面,根据需要会做成不同的关系,但从实际情况讲,部门和人员应该是多对多的,也就是一个部门可以有多个人,而一个人也可以加入多个部门。

       对于一个部门有多个人,估计大家都能理解。而一个人也可以加入多个部门,或许有些朋友就觉得有些问题了,因为在他们做系统的经验上,是一个人只属于一个部门的。

事实上一个人是可以属于多个部门的,比如:某人是开发部的经理,同时也是销售部门的技术总监,为销售部门给客户的解决方案中的技术部分进行把关,同时还可以是客户服务部门的技术顾问,为他们解决客户的技术问题提供指导。

       好了,理解了部门和人员是多对多的关系过后,有些朋友可能会做出如下的设计,不就是个多对多吗,类之间的多对多也很容易表达啊,如下:

public class Dep {

    private Collection<User> colUser = new ArrayList<User>();

}

public class User {

    private Collection<Dep> colDep = new ArrayList<Dep>();

}

很简单,是吧,一个部门有多个人员,一个人员属于多个部门。

2:问题的出现

    真的这么简单吗?再进一步想想部门和人员的功能交互,就会知道这样设计是存在问题的,举几个常见的功能:

  • 部门被撤销
  • 部门之间进行合并
  • 人员离职
  • 人员从一个部门调职到另外一个部门

想想要实现这些功能,按照前面的设计,该怎么做呢?

(1)系统运行期间,部门被撤销了,就意味着这个部门不存在了,可是原来这个部门下所有的人员,每个人员的所属部门中都有这个部门呢,那么就需要先通知所有的人员,把这个部门从它们的所属部门中去掉,然后才可以清除这个部门。

(2)部门合并,是合并成一个新的部门呢,还是把一个部门并入到另一个部门?如果是合并成一个新的部门,那么需要把原有的两个部门撤销,然后再新增一个部门;如果是把一个部门合并到另一个部门里面,那就是撤销掉一个部门,然后把这个部门下的人员移动到这个部门。不管是那种情况,都面临着需要通知相应的人员进行更改这样的问题。

(3)人员离职了,反过来就需要通知他所属于的部门,从部门的拥有人员的记录中去除掉这个人员。

(4)人员调职,同样需要通知相关的部门,先从原来的部门中去除掉,然后再到新的部门中添加上。

看了上述的描述,感觉如何?是不是“烦就一个字”啊!

       麻烦的根源在什么地方呢?仔细想想,对了,麻烦的根源就在于部门和人员之间的耦合,这样导致操作人员的时候,需要操作所有相关的部门,而操作部门的时候又需要操作所有相关的人员,使得部门和人员搅和在了一起。

3:中介者来解决

找到了根源就好办了,采用中介者模式,引入一个中介者对象来管理部门和人员之间的关系,就能解决这些问题了。

如果采用标准的中介者模式,想想上面提出的那些问题点吧,就知道实现起来会很别扭。因此采用广义的中介者来解决,这样部门和人员就完全解耦了,也就是说部门不知道人员,人员也不知道部门,它们完全分开,它们之间的关系就完全由中介者对象来管理了。这个时候的结构如图10.6所示:

 

图10.6  引入中介者后的结构示意图

好了,还是看代码示例会比较清晰。

4:实现示例   

(1)首先定义部门类,示例代码如下:

/**

 * 部门类

 */

public class Dep{

    /**

     * 描述部门编号

     */

    private String depId;

    /**

     * 描述部门名称

     */

    private String depName;

 

    public String getDepId() {

       return depId;

    }

    public void setDepId(String depId) {

       this.depId = depId;

    }

    public String getDepName() {

       return depName;

    }

    public void setDepName(String depName) {

       this.depName = depName;

    }

    /**

     * 撤销部门

     * @return 是否撤销成功

     */

    public boolean deleteDep(){

       //1:要先通过中介者去清除掉所有与这个部门相关的部门和人员的关系

       DepUserMediatorImpl mediator =

DepUserMediatorImpl.getInstance();

       mediator.deleteDep(depId);

       //2:然后才能真的清除掉这个部门

       //请注意在实际开发中,这些业务功能可能会做到业务层去,

       //而且实际开发中对于已经使用的业务数据通常是不会被删除的,

       //而是会被做为历史数据保留

       return true;

    }

}

(2)接下来定义人员类,示例代码如下:

/**

 * 人员类

 */

public class User{

    /**

     * 人员编号

     */

    private String userId;

    /**

     * 人员名称

     */

    private String userName;

 

    public String getUserId() {

       return userId;

    }

    public void setUserId(String userId) {

       this.userId = userId;

    }

    public String getUserName() {

       return userName;

    }

    public void setUserName(String userName) {

       this.userName = userName;

    }

    /**

     * 人员离职

     * @return 是否处理成功

     */

    public boolean dimission(){

       //1:要先通过中介者去清除掉所有与这个人员相关的部门和人员的关系

       DepUserMediatorImpl mediator =

DepUserMediatorImpl.getInstance();

       mediator.deleteUser(userId);

       //2:然后才能真的清除掉这个人员

       //请注意,实际开发中,人员离职,是不会真的删除人员记录的,

       //通常是把人员记录的状态或者是删除标记设置成已删除,

       //只是不再参加新的业务,但是已经发生的业务记录是不会被清除掉的    

 

       return true;

    }

}

(3)顺带看一下描述部门和人员关系的对象,非常简单,示例代码如下:

/**

 *  描述部门和人员关系的类

 */

public class DepUserModel {

    /**

     * 用于部门和人员关系的编号,用做主键

     */

    private String depUserId;

    /**

     * 部门的编号

     */

    private String depId;

    /**

     * 人员的编号

     */

    private String userId;

   

   

   

}

(4)具体的中介者实现

首先中介者要管理部门和人员的关系,所以在中介者实现里面添加了一些测试的数据,为此还专门做了一个用来描述部门和人员关系的数据对象;其次在中介者里面只是实现了撤销部门和人员离职相应的关系处理,其它的没有实现;另外,这个中介者实现被实现成单例的了。示例代码如下:

/**

 * 实现部门和人员交互的中介者实现类

 * 说明:为了演示的简洁性,只示例实现撤销部门和人员离职的功能

 */

public class DepUserMediatorImpl{

    private static DepUserMediatorImpl mediator =

new DepUserMediatorImpl();

    private DepUserMediatorImpl(){

       //调用初始化测试数据的功能

       initTestData();

    }

    public static DepUserMediatorImpl getInstance(){

       return mediator;

    }

   

    /**

     * 测试用,记录部门和人员的关系

     */

    private Collection<DepUserModel> depUserCol =

new ArrayList<DepUserModel>();

    /**

     * 初始化测试数据

     */

    private void initTestData(){

       //准备一些测试数据

       DepUserModel du1 = new DepUserModel();

       du1.setDepUserId("du1");

       du1.setDepId("d1");

       du1.setUserId("u1");    

       depUserCol.add(du1);

      

       DepUserModel du2 = new DepUserModel();

       du2.setDepUserId("du2");

       du2.setDepId("d1");

       du2.setUserId("u2");    

       depUserCol.add(du2);

      

       DepUserModel du3 = new DepUserModel();

       du3.setDepUserId("du3");

       du3.setDepId("d2");

       du3.setUserId("u3");    

       depUserCol.add(du3);

      

       DepUserModel du4 = new DepUserModel();

       du4.setDepUserId("du4");

       du4.setDepId("d2");

       du4.setUserId("u4");    

       depUserCol.add(du4);

      

       DepUserModel du5 = new DepUserModel();

       du5.setDepUserId("du5");

       du5.setDepId("d2");

       du5.setUserId("u1");    

       depUserCol.add(du5);

    }

    /**

     * 完成因撤销部门的操作所引起的与人员的交互,需要去除相应的关系

     * @param depId 被撤销的部门对象的编号

     * @return 是否已经正确的处理了因撤销部门所引起的与人员的交互

     */

    public boolean deleteDep(String depId) {

       //请注意:为了演示简单,部门撤销后,

       //原部门的人员怎么处理等后续业务处理,这里就不管了

      

       //1:到记录部门和人员关系的集合里面,寻找跟这个部门相关的人员

       //设置一个临时的集合,记录需要清除的关系对象

       Collection<DepUserModel> tempCol =

new ArrayList<DepUserModel>();

       for(DepUserModel du : depUserCol){

           if(du.getDepId().equals(depId)){

              //2:需要把这个相关的记录去掉,先记录下来

              tempCol.add(du);

           }

       }

       //3:从关系集合里面清除掉这些关系

       depUserCol.removeAll(tempCol);

      

       return true;

    }

    /**

     * 完成因人员离职引起的与部门的交互

     * @param userId 离职的人员的编号

     * @return 是否正确处理了因人员离职引起的与部门的交互

     */

    public boolean deleteUser(String userId) {

       //1:到记录部门和人员关系的集合里面,寻找跟这个人员相关的部门

       //设置一个临时的集合,记录需要清除的关系对象

       Collection<DepUserModel> tempCol =

new ArrayList<DepUserModel>();

       for(DepUserModel du : depUserCol){

           if(du.getUserId().equals(userId)){

              //2:需要把这个相关的记录去掉,先记录下来

              tempCol.add(du);

           }

       }

       //3:从关系集合里面清除掉这些关系

       depUserCol.removeAll(tempCol);

   

       return true;

    }

    /**

     * 测试用,在内部打印显示一下一个部门下的所有人员

     * @param dep 部门对象

     */

    public void showDepUsers(Dep dep) {

       for(DepUserModel du : depUserCol){

           if(du.getDepId().equals(dep.getDepId())){

              System.out.println("部门编号="+dep.getDepId()

+"下面拥有人员,其编号是:"+du.getUserId());

           }

       }

    }

    /**

     * 测试用,在内部打印显示一下一个人员所属的部门

     * @param user 人员对象

     */

    public void showUserDeps(User user) {

       for(DepUserModel du : depUserCol){

           if(du.getUserId().equals(user.getUserId())){

              System.out.println("人员编号="+user.getUserId()

+"属于部门编号是:"+du.getDepId());

           }

       }

    }

    /**

     * 完成因人员调换部门引起的与部门的交互

     * @param userId 被调换的人员的编号

     * @param oldDepId 调换前的部门的编号

     * @param newDepId 调换后的部门的编号

     * @return 是否正确处理了因人员调换部门引起的与部门的交互

     */

    public boolean changeDep(String userId,String oldDepId

, String newDepId) {

       //本示例不去实现了

        return false;

    }

    /**

     * 完成因部门合并操作所引起的与人员的交互

     * @param colDepIds 需要合并的部门的编号集合

     * @param newDep 合并后新的部门对象

     * @return 是否正确处理了因部门合并操作所引起的与人员的交互

     */

    public boolean joinDep(Collection<String> colDepIds

, Dep newDep){

       //本示例不去实现了     

       return false;

    }

}

(5)测试一下,看看好用不,客户端示例代码如下:

public class Client {

    public static void main(String[] args) {

       DepUserMediatorImpl mediator =

DepUserMediatorImpl.getInstance();

       //准备要撤销的部门,仅仅需要一个部门编号

       Dep dep = new Dep();

       dep.setDepId("d1");

       Dep dep2 = new Dep();

       dep2.setDepId("d2");

       //准备用于测试的人员,也只需要一个人员编号

       User user = new User();

       user.setUserId("u1");

      

       //测试撤销部门,在运行之前,输出一下,看这个人员属于哪些部门      

       System.out.println("撤销部门前------------------");

       mediator.showUserDeps(user);      

       //真正执行业务,撤销这个部门

       dep.deleteDep();    

       //再次输出一下,看这个人员属于哪些部门

       System.out.println("撤销部门后------------------");

       mediator.showUserDeps(user);

      

       //测试人员离职,在运行之前,输出一下,看这个部门下都有哪些人员

       System.out.println("---------------------------------");

       System.out.println("人员离职前------------------");

       mediator.showDepUsers(dep2);      

       //真正执行业务,人员离职

       user.dimission();   

       //再次输出一下,看这个部门下都有哪些人员

       System.out.println("人员离职后------------------");

       mediator.showDepUsers(dep2);

    }

}

测试结果如下:

撤销部门前------------------

人员编号=u1属于部门编号是:d1

人员编号=u1属于部门编号是:d2

撤销部门后------------------

人员编号=u1属于部门编号是:d2

---------------------------------

人员离职前------------------

部门编号=d2下面拥有人员,其编号是:u3

部门编号=d2下面拥有人员,其编号是:u4

部门编号=d2下面拥有人员,其编号是:u1

人员离职后------------------

部门编号=d2下面拥有人员,其编号是:u3

部门编号=d2下面拥有人员,其编号是:u4

好好体会一下,看看这样做是不是变得更容易了些,而且也实现了中介者想要实现的功能,那就是让同事对象相互分离,由中介对象统一管理它们的交互。

10.3.3  中介者模式的优缺点

l          松散耦合
    中介者模式通过把多个同事对象之间的交互封装到中介者对象里面,从而使得同事对象之间松散耦合,基本上可以做到互不依赖。这样一来,同事对象就可以独立的变化和复用,而不再像以前那样“牵一发而动全身”了。

l          集中控制交互
    多个同事对象的交互,被封装在中介者对象里面集中管理,使得这些交互行为发生变化的时候,只需要修改中介者对象就可以了,当然如果是已经做好的系统,那就扩展中介者对象,而各个同事类不需要做修改。

l          多对多变成一对多
    没有使用中介者模式的时候,同事对象之间的关系通常是多对多的,引入中介者对象过后,中介者对象和同事对象的关系通常变成了双向的一对多,这会让对象的关系更容易理解和实现。

l          过度集中化
    中介者模式的一个潜在缺点是,如果同事对象的交互非常多,而且比较复杂,当这些复杂性全部集中到中介者的时候,会导致中介者对象变得十分的复杂,而且难于管理和维护。

10.3.4  思考中介者模式

1:中介者模式的本质

中介者模式的本质:封装交互

中介者模式的目的,就是用来封装多个对象的交互,这些交互的处理多在中介者对象里面实现,因此中介对象的复杂程度,就取决于它封装的交互有多复杂了。

       只要是实现封装对象之间的交互功能,就可以应用上中介者模式,而不必过于拘泥于中介者模式本身的结构。标准的中介者模式限制很多,导致能完全按照标准使用中介者模式的地方并不是很多,而且多集中在界面实现上。只要本质不变,稍稍变形一下,简化一下,或许能更好的使用中介者模式。

2:何时选用中介者模式

建议在如下情况中,选用中介者模式:

  • 如果一组对象之间的通信方式比较复杂,导致相互依赖、结构混乱,可以采用中介者模式,把这些对象相互的交互管理起来,各个对象都只需要和中介者交互,从而使得各个对象松散耦合,结构也更清晰易懂。
  • 如果一个对象引用很多的对象,并直接跟这些对象交互,导致难以复用该对象。可以采用中介者模式,把这个对象跟其它对象的交互封装到中介者对象里面,这个对象就只需要和中介者对象交互就可以了。

10.3.5  相关模式

l          中介者模式和外观模式
    这两个模式有相似的地方,也存在很大的不同。
    外观模式多用来封装一个子系统内部的多个模块,目的是向子系统外部提供简单易用的接口,也就是说外观模式封装的是子系统外部和子系统内部模块间的交互;而中介者模式是提供多个平等的同事对象之间交互关系的封装,一般是用在内部实现上。
    另外,外观模式是实现单向的交互,是从子系统外部来调用子系统内部,不会反着来,而中介者模式实现的是内部多个模块间多向的交互。

l          中介者模式和观察者模式
    这两个模式可以组合使用。
    中介者模式可以组合使用观察者模式,来实现当同事对象发生改变的时候,通知中介对象,让中介对象去进行与其它相关对象的交互。

 


---------------------------------------------------------------------------

私塾在线学习网原创内容  跟着cc学设计系列 之 研磨设计模式

原创内容,转载请注明出处【http://sishuok.com/forum/blogPost/list/5109.html

---------------------------------------------------------------------------

相关笔记推荐
精品视频课程推荐

Java数据结构和算法精讲版
本课程专注于数据结构和算法的内容,使用Java来进行代码示例,不空洞的讲解概念和理论,重点放在代码的实现和示例上。 从零开始、全面系统、成体系的讲解数据结构和基本算法,循序渐进的讲述构建软件系统所常见的数据结构和算法。

Ajax+JSON基础实战视频教程
数据校验、Javascript模拟多线程、下拉列表联动、操作XML、AJAX结合JSON的操作、Json-lib的使用

XML基础视频教程
创建规范的XML文档,DTD的作用,并且可以根据要求创建私用的DTD,通过JavaScript解析XML DOM

深入浅出学Spring Web MVC视频教程
系统、完整的学习Spring Web MVC开发的知识。包括:Spring Web MVC入门;理解DispatcherServlet;注解式控制器开发详解;数据类型转换;数据格式化;数据验证; 拦截器;对Ajax的支持;文件上传下载;表单标签等内容;最后以一个综合的CRUD带翻页的应用示例来综合所学的知识

freevoice(局域网对讲机)——Android4项目实战视频教程
实现通过Wifi来在局域网内相互传递信息和语音通话的功能;学习Service;Broadcast Receiver;SharedPreference;SQLite;语音录制、播放、传输等;网络开发:wifi处理、UDP编程、TCP编程;多种设计模式的应用 等等

浏览(8299)|评论(1)   交流分类:Java|笔记分类: 研磨设计模式

评论(1)
1楼 seekbug  2013-01-18 引用
已阅。
本质:封装交互,松散(对象间)耦合。
请登录后评论 登录

关于我们 | 联系我们 | 用户协议 | 私塾在线服务协议 | 版权声明 | 隐私保护

版权所有 Copyright(C)2009-2012 私塾在线学习网