研磨设计模式 试读 (第24章)

 

 
第24章 桥接模式(Bridge)


考虑这样一个实际的业务功能:发送提示消息。基本上所有带业务流程处理的系统都会有这样的功能,比如某人有新的工作了,需要发送一条消息提示他。
从业务上看,消息又分成普通消息、加急消息和特急消息多种。不同的消息类型,业务功能处理是不一样的,比如加急消息是在消息上添加加急,而特急消息除了添加特急外,还会做一条催促的记录,多久不完成会继续催促,从发送消息的手段上看,又有系统内短消息、手机短消息、邮件等。
现在要实现这样的发送提示消息的功能,该如何实现呢?
24.1.2 不用模式的解决方案
1:实现简化版本
先考虑实现一个简单点的版本,比如,消息只是实现发送普通消息,发送的方式呢,只实现系统内短消息和邮件。其他的功能,等这个版本完成后,再继续添加。这样先把问题简单化,实现起来会容易一点。
由于发送普通消息会有两种不同的实现方式,为了让外部能统一操作,因此,把消息设计成接口,然后由两个不同的实现类。分别实现系统内短消息方式和邮件发送消息的方式。此时系统结构如图24.1所示。
图24.1 简化版本的系统结构示意图
下面看看大致的实现示意。
(1)先来看看消息的统一接口。示例代码如下:

/**
 * 消息的统一接口
 */
public interface Message {
    /**
     * 发送消息
     * @param message 要发送的消息内容
     * @param toUser 消息发送的目的人员
     */
    public void send(String message,String toUser);
}

(2)再来分别看看两种实现方式。这里只是为了示意,并不会真的去发送E-mail和站内短消息。
先看看站内短消息的方式。示例代码如下:

/**
 * 以站内短消息的方式发送普通消息
 */
public  class CommonMessageSMS implements Message{
    public void send(String message, String toUser) {
        System.out.println(" 使用站内短消息的方式,发送消息 '"
+message+"' "+toUser);
    }
}

同样地,实现以E-mail的方式发送普通消息。示例代码如下:

/**
 * E-mail 的方式发送普通消息
 */
public class CommonMessageEmail implements Message{
    public void send(String message, String toUser) {
        System.out.println(" 使用 E-mail 的方式,发送消息 '"
+message+"' "+toUser);
    }
}

2:实现发送加急消息
         上面的实现看起来很简单,对不对?接下来,添加发送加急消息的功能,也有两种发送的方式,同样是站内短消息和E-mail的方式。
         加急消息的实现不同于普通消息。加急消息会自动在消息上添加加急,然后再发送消息;另外加急消息会提供监控的方法,让客户端可以随时通过这个方法来了解对于加急消息处理的进度,比如,相应的人员是否接收到这个信息,相应的工作是否已经开展等。因此加急消息需要扩展出一个新的接口,除了基本的发送消息的功能,还需要添加监控的功能。这个时候,系统的结构如图24.2所示。
图24.2 加入发送加急消息后的系统结构示意图
(1)先看看扩展出来的加急消息的接口。示例代码如下:

/**
 * 加急消息的抽象接口
 */
public interface UrgencyMessage extends Message{
    /**
     * 监控某消息的处理过程
     * @param messageId 被监控的消息的编号
     * @return 包含监控到的数据对象,这里示意一下,所以用了Object
     */
    public Object watch(String messageId);
}

(2)相应的实现方式还是发送站内短消息和E-mail两种,同样需要两个实现类来分别实现这两种方式。
先看看站内短消息的方式。示例代码如下:

public class UrgencyMessageSMS implements UrgencyMessage{
    public void send(String message, String toUser) {
        message = "加急:"+message;
        System.out.println(" 使用站内短消息的方式,发送消息 '"
+message+"' "+toUser);
    }
 
    public Object watch(String messageId) {
        //获取相应的数据,组织成监控的数据对象,然后返回      
        return null;
    }  
}

再看看E-mail的方式.示例代码如下:

public class UrgencyMessageEmail implements UrgencyMessage{
    public void send(String message, String toUser) {
        message = "加急:"+message;
        System.out.println(" 使用 Email 的方式,发送消息 '"
+message+"' "+toUser);
    }
    public Object watch(String messageId) {
        //获取相应的数据,组织成监控的数据对象,然后返回      
        return null;
    }  
}

(3)事实上,在实现加急消息发送的功能上,可能会使用前面发送不同消息的功能,也就是让实现加急消息处理的对象继承普通消息的相应实现。但这里为了让结构简单、清晰一点,所以没有这样做。
上面这样实现,好像也能满足基本的功能要求,可是这么实现好不好呢?有没有什么问题呢?
咱们继续向下来添加功能实现。为了简洁,就不再进行代码示意了,通过实现的结构示意图就可以看出实现上的问题。
1:继续添加特急消息的处理
特急消息不需要查看处理进程,只要没有完成,就直接催促,也就是说,对于特急消息,在普通消息的处理基础上,需要添加催促的功能。而特急消息和催促的发送方式,相应的实现方式还是发送站内短消息和E-mail两种。此时系统的结构如图24.3所示。
图24.3 加入发送特急消息后的系统结构示意图
仔细观察上面的系统结构示意图,会发现一个很明显的问题,那就是通过这种继承的方式来扩展消息处理,会非常不方便。
会看到在实现加急消息处理的时候,必须实现站内短消息和E-mail两种处理方式,因为业务处理可能不同;在实现特急消息处理的时候,又必须实现站内短消息和E-mail这两种处理方式。
这意味着,以后每次扩展一下消息处理,都必须要实现这两种处理方式,是不是很痛苦?这还不算完,如果要添加新的实现方式呢?继续向下看吧。
2:继续添加发送手机消息的处理方式
         如果看到上面的实现,你还感觉问题不是很大的话,继续完成功能,添加发送手机消息的处理方式。
仔细观察现在的实现,如果要添加一种新的发送消息的方式,是需要在每一种抽象的具体实现中,都要添加发送手机消息的处理的。也就是说,发送普通消息、加急消息和特急消息的处理,都可以通过手机来发送。这就意味着,需要添加三个实现。此时系统结构如图24.4所示。
图24.4 加入发送手机消息后的系统结构示意图
         现在体会到这种实现方式的大问题了吧。
3:小结一下出现的问题
采用通过继承来扩展的实现方式,有个明显的缺点,扩展消息的种类不太容易。不同种类的消息具有不同的业务,也就是有不同的实现,在这种情况下,每个种类的消息,需要实现所有不同的消息发送方式。
更可怕的是,如果要新加入一种消息的发送方式,那么会要求所有的消息种类都要加入这种新的发送方式的实现。
要是考虑业务功能上再扩展一下呢?比如,要求实现群发消息,也就是一次可以发送多条消息,这就意味着很多地方都得修改,太恐怖了。
那么究竟该如何实现才能既实现功能,又能灵活地扩展呢?
24.2.1 使用桥接模式来解决问题
用来解决上述问题的一个合理的解决方案,就是使用桥接模式。那么什么是桥接模式呢?

将抽象部分与它的实现部分分离,使它们都可以独立地变化。

 
1:桥接模式的定义

 

 
2:应用桥接模式来解决问题的思路
仔细分析上面的示例,根据示例的功能要求,示例的变化具有两个纬度,一个纬度是抽象的消息这边,包括普通消息、加急消息和特急消息,这几个抽象的消息本身就具有一定的关系,加急消息和特急消息会扩展普通消息;另一个纬度是在具体的消息发送方式上,包括站内短消息、E-mail和手机短信息,这几个方式是平等的,可被切换的方式。这两个纬度一共可以组合出9种不同的可能性来。它们的关系如图24.5所示。

消息类型

 
普通消息
加急消息
加急消息
发送消息的方式
站内短消息
E-mail
手机短消息

 

现在出现问题的根本原因,就在于消息的抽象和实现是混杂在一起的,这就导致了,一个纬度的变化会引起另一个纬度进行相应的变化,从而使得程序扩展起来非常困难。

 
提示
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
图24.5 发送消息的可能性的组合示意图

 

要想解决这个问题,就必须把这两个纬度分开,也就是将抽象部分和实现部分分开,让它们相互独立,这样就可以实现独立的变化,使扩展变得简单。
桥接模式通过引入实现的接口,把实现部分从系统中分离出去。那么,抽象这边如何使用具体的实现呢?肯定是用面向实现的接口来编程了,为了让抽象这边能够很方便地与实现结合起来,把顶层的抽象接口改成抽象类,在中持有一个具体的实现部分的实例。
这样一来,对于需要发送消息的客户端而言,就只需要创建相应的消息对象,然后调用这个消息对象的方法就可以了,这个消息对象会调用持有的真正的消息发送方式来把消息发送出去。也就是说客户端只是想要发送消息而已,并不想关心具体如何发送。
桥接模式的结构如图24.6所示。
图24.6 桥接模式的结构示意图
Abstraction:抽象部分的接口。通常在这个对象中,要维护一个实现部分的对象引用,抽象对象里面的方法,需要调用实现部分的对象来完成。这个对象中的方法,通常都是和具体的业务相关的方法。
RefinedAbstraction:扩展抽象部分的接口。通常在这些对象中,定义跟实际业务相关的方法,这些方法的实现通常会使用Abstraction中定义的方法,也可能需要调用实现部分的对象来完成。
Implementor:定义实现部分的接口。这个接口不用和Abstraction中的方法一致,通常是由Implementor接口提供基本的操作。而Abstraction中定义的是基于这些基本操作的业务方法,也就是说Abstraction定义了基于这些基本操作的较高层次的操作。
ConcreteImplementor:真正实现Implementor接口的对象。
(1)先看看Implementor接口的定义。示例代码如下:
/**
 * 定义实现部分的接口,可以与抽象部分接口的方法不一样
 */
public interface Implementor {
    /**
     * 示例方法,实现抽象部分需要的某些具体功能
     */
    public void operationImpl();
}
(2)再看看Abstraction接口的定义。注意一点,虽然说是接口定义,但其实是实现成为抽象类。示例代码如下:
/**
 * 定义抽象部分的接口
 */
public abstract class Abstraction {
    /**
     * 持有一个实现部分的对象
     */
    protected Implementor impl;
    /**
     * 构造方法,传入实现部分的对象
     * @param impl 实现部分的对象
     */
    public Abstraction(Implementor impl){
        this.impl = impl;
    }
    /**
     * 示例操作,实现一定的功能,可能需要转调实现部分的具体实现方法
     */
    public void operation() {
        impl.operationImpl();
    }
}
(3)接下来看看具体的实现。其中一个实现的示例代码如下:
/**
 * 真正的具体实现对象
 */
public class ConcreteImplementorA implements Implementor {
    public void operationImpl() {
        //真正的实现
    }
}
另外一个实现。示例代码如下:
/**
 * 真正的具体实现对象
 */
public class ConcreteImplementorB implements Implementor {
    public void operationImpl() {
        //真正的实现
    }
}
(4)最后来看看扩展Abstraction接口的对象实现。示例代码如下:
/**
 * 扩充由Abstraction定义的接口功能
 */
public class RefinedAbstraction extends Abstraction {
    public RefinedAbstraction(Implementor impl) {
        super(impl);
    }
    /**
     * 示例操作,实现一定的功能
     */
    public void otherOperation(){
        //实现一定的功能,可能会使用具体实现部分的实现方法
        //但是本方法更大的可能是使用Abstraction中定义的方法
        //通过组合使用Abstraction中定义的方法来完成更多的功能
    }
}
24.2.4 使用桥接模式重写示例
         学习了桥接模式的基础知识,该来使用桥接模式重写前面的示例了。通过示例,来看看使用桥接模式来实现同样的功能,是否能解决“既能方便地实现功能,又能有很好的扩展性”的问题。
         要使用桥接模式来重新实现前面的示例,首要任务就是要把抽象部分和实现部分分离出来,分析要实现的功能。抽象部分就是各个消息的类型所对应的功能,而实现部分就是各种发送消息的方式。
其次要按照桥接模式的结构,给抽象部分和实现部分分别定义接口,然后分别实现它们就可以了。
1:从简单功能开始
         从相对简单的功能开始,先实现普通消息和加急消息的功能,发送方式先实现站内短消息和E-mail两种。     
使用桥接模式来实现这些功能的程序结构如图24.7所示。
图24.7 使用桥接模式来实现简单功能示例的程序结构示意图
         下面看看代码实现,会更清楚一些。
(1)先看看实现部分定义的接口。示例代码如下:
/**
 * 实现发送消息的统一接口
 */
public interface MessageImplementor {
    /**
     * 发送消息
     * @param message 要发送的消息内容
     * @param toUser 消息发送的目的人员
     */
    public void send(String message,String toUser);
}
(2)再看看抽象部分定义的接口。示例代码如下:
/**
 * 抽象的消息对象
 */
public abstract class AbstractMessage {
    /**
     * 持有一个实现部分的对象
     */
    protected MessageImplementor impl;
    /**
     * 构造方法,传入实现部分的对象
     * @param impl 实现部分的对象
     */
    public AbstractMessage(MessageImplementor impl){
        this.impl = impl;
    }
    /**
     * 发送消息,转调实现部分的方法
     * @param message 要发送的消息内容
     * @param toUser 消息发送的目的人员
     */
    public void sendMessage(String message,String toUser){
        this.impl.send(message, toUser);
    }  
}
(3)看看如何具体地实现发送消息。
先看看站内短消息的实现吧。示例代码如下:
/**
 * 以站内短消息的方式发送消息
 */
public class MessageSMS implements MessageImplementor{
    public void send(String message, String toUser) {
        System.out.println(" 使用站内短消息的方式,发送消息 '"
+message+"' "+toUser);
    }
}
         再看看E-mail方式的实现。示例代码如下:
/**
 * 以E-mail的方式发送消息
 */
public class MessageEmail implements MessageImplementor{
    public void send(String message, String toUser) {
        System.out.println(" 使用 E-mail 的方式,发送消息 '"
+message+"' "+toUser);
    }
}
(4)接下来该看看如何扩展抽象的消息接口了。
先看看普通消息的实现。示例代码如下:
public class CommonMessage extends AbstractMessage{
    public CommonMessage(MessageImplementor impl) {
        super(impl);
    }
    public void sendMessage(String message, String toUser) {
        //对于普通消息,什么都不干,直接调用父类的方法,把消息发送出去就可以了
        super.sendMessage(message, toUser);
    }  
}
         再看看加急消息的实现。示例代码如下:
public class UrgencyMessage extends AbstractMessage{
    public UrgencyMessage(MessageImplementor impl) {
        super(impl);
    }
    public void sendMessage(String message, String toUser) {
        message = " 加急: "+message;
        super.sendMessage(message, toUser);
    }
    /**
     * 扩展自己的新功能:监控某消息的处理过程
     * @param messageId 被监控的消息的编号
     * @return 包含监控到的数据对象,这里示意一下,所以用了Object
     */
    public Object watch(String messageId) {
        //获取相应的数据,组织成监控的数据对象,然后返回      
        return null;
    }  
}
2:添加功能
         看了上面的实现,发现使用桥接模式来实现也不是很困难,关键得看是否能解决前面提出的问题,那就来添加还未实现的功能看看,添加对特急消息的处理,同时添加一个使用手机发送消息的方式,该怎么实现呢?
很简单,只需要在抽象部分再添加一个特急消息的类,扩展抽象消息就可以把特急消息的处理功能加入到系统中;对于添加手机发送消息的方式也很简单,在实现部分新增加一个实现类,实现用手机发送消息的方式就可以了。
         这么简单?好像看起来完全没有了前面所提到的问题。的确如此,采用桥接模式来实现,抽象部分和实现部分分离开了,可以相互独立地变化,而不会相互影响。因此在抽象部分添加新的消息处理,对发送消息的实现部分是没有影响的;反过来增加发送消息的方式,对消息处理部分也是没有影响的。
(1)接着看看代码实现。
先看看新的特急消息的处理类。示例代码如下:
public class SpecialUrgencyMessage extends AbstractMessage{
    public SpecialUrgencyMessage(MessageImplementor impl) {
        super(impl);
    }
    public void hurry(String messageId) {
        // 执行催促的业务,发出催促的信息
    }
    public void sendMessage(String message, String toUser) {
        message = "特急:"+message;
        super.sendMessage(message, toUser);
        //还需要增加一条待催促的信息
    }
}
(2)再看看使用手机短消息的方式发送消息的实现。示例代码如下:
/**
 * 以手机短消息的方式发送消息
 */
public class MessageMobile implements MessageImplementor{
    public void send(String message, String toUser) {
        System.out.println(" 使用手机短消息的方式,发送消息 '"
+message+"' "+toUser);
    }
}
3:测试功能
         看了上面的实现,可能会感觉到,使用桥接模式来实现前面的示例,添加新的消息处理,或者是新的消息发送方式是如此简单,可是这样实现,好用吗?写个客户端来测试和体会一下。示例代码如下:
public class Client {
    public static void main(String[] args) {
        //创建具体的实现对象
        MessageImplementor impl = new MessageSMS();
        //创建一个普通消息对象
        AbstractMessage m = new CommonMessage(impl);
        m.sendMessage("请喝一杯茶", "小李");     
        //创建一个紧急消息对象
        m = new UrgencyMessage(impl);
        m.sendMessage("请喝一杯茶", "小李");     
        //创建一个特急消息对象
        m = new SpecialUrgencyMessage(impl);
        m.sendMessage("请喝一杯茶", "小李");
       
        //把实现方式切换成手机短消息,然后再实现一遍
        impl = new MessageMobile();
        m = new CommonMessage(impl);
        m.sendMessage("请喝一杯茶", "小李");
        m = new UrgencyMessage(impl);
        m.sendMessage("请喝一杯茶", "小李");
        m = new SpecialUrgencyMessage(impl);
        m.sendMessage("请喝一杯茶", "小李");
    }
}
运行结果如下:
使用站内短消息的方式,发送消息'请喝一杯茶'给小李
使用站内短消息的方式,发送消息'加急:请喝一杯茶'给小李
使用站内短消息的方式,发送消息'特急:请喝一杯茶'给小李
使用手机短消息的方式,发送消息'请喝一杯茶'给小李
使用手机短消息的方式,发送消息'加急:请喝一杯茶'给小李
使用手机短消息的方式,发送消息'特急:请喝一杯茶'给小李
         前面三条是使用的站内短消息,后面三条是使用的手机短消息,正确的实现了预期的功能。看来前面的实现应该是正确的,能够完成功能,且能灵活扩展。
1:什么是桥接
         在桥接模式中,不太好理解的就是桥接的概念。什么是桥接?为何需要桥接?如何桥接?把这些问题搞清楚了,也就基本明白桥接的含义了。

注意

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
但是这里要注意一个问题,在桥接模式中的桥接是单向的,也就是只能是抽象部分的对象去使用具体实现部分的对象,而不能反过来,也就是个单向桥。
         一个一个来,先看看什么是桥接?所谓桥接,通俗点说就是在不同的东西之间搭一个桥,让它们能够连接起来,可以相互通讯和使用。那么在桥接模式中到底是给什么东西来搭桥呢?就是为被分离了的抽象部分和实现部分来搭桥,比如前面示例中在抽象的消息和具体消息发送之间搭个桥。

 

        
2:为何需要桥接
         为了达到让抽象部分和实现部分都可以独立变化的目的,在桥接模式中,是把抽象部分和实现部分分离开来的,虽然从程序结构上是分开了,但是在抽象部分实现的时候,还是需要使用具体的实现的,这可怎么办呢?抽象部分如何才能调用到具体实现部分的功能呢?很简单,搭个桥就可以了。搭个桥,让抽象部分通过这个桥就可以调用到实现部分的功能了,因此需要桥接。
3:如何桥接
         这个理解上也很简单,只要让抽象部分拥有实现部分的接口对象,就桥接上了,在抽象部分即可通过这个接口来调用具体实现部分的功能。也就是说,桥接在程序上体现了在抽象部分拥有实现部分的接口对象,维护桥接就是维护这个关系。
4:独立变化

延伸

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
如果这么看桥接模式的话,就类似于策略模式了。抽象部分需要根据某个策略,来选择真实的实现,也就是说桥接模式的抽象部分相当于策略模式的上下文。更原始的就直接类似于面向接口编程,通过接口分离的两个部分而已。但是别忘了,桥接模式的抽象部分,是可以继续扩展和变化的,而策略模式只有上下文,是不存在所谓抽象部分的。
         桥接模式的意图是使得抽象和实现可以独立变化,都可以分别扩充。也就是说抽象部分和实现部分是一种非常松散的关系。从某个角度来讲,抽象部分和实现部分是可以完全分开的,独立的,抽象部分不过是一个使用实现部分对外接口的程序罢了。

 

        
         那抽象和实现为何还要组合在一起呢?原因是在抽象部分和实现部分还是存在内部联系的,抽象部分的实现通常是需要调用实现部分的功能来实现的。
5:动态变换功能
         由于桥接模式中的抽象部分和实现部分是完全分离的,因此可以在运行时动态组合具体的真实实现,从而达到动态变换功能的目的。
         从另外一个角度看,抽象部分和实现部分没有固定的绑定关系,因此同一个真实实现可以被不同的抽象对象使用;反过来,同一个抽象也可以有多个不同的实现。就像前面示例的那样,比如,站内短消息的实现功能,可以被普通消息、加急消息或是特急消息等不同的消息对象使用;反过来,某个消息具体的发送方式,可以是站内短消息,或者是E-mail,也可以是手机短消息等具体的发送方式。
6:退化的桥接模式
         如果Implementor仅有一个实现,那么就没有必要创建Implementor接口了,这是一种桥接模式退化的情况。这个时候Abstraction和Implementor是一对一的关系,虽然如此,也还是要保持它们的分离状态,这样的话,它们才不会相互影响,才可以分别扩展。
也就是说,就算不要Implementor接口了,也要保持Abstraction和Implementor是分离的,模式的分离机制仍然是非常有用的。
7:桥接模式和继承
         继承是扩展对象功能的一种常见手段,通常情况下,继承扩展的功能变化纬度都是一纬的,也就是变化的因素只有一类。
         对于出现变化因素有两类的,也就是有两个变化纬度的情况,继承实现就会比较痛苦。比如上面的示例,就有两个变化纬度,一个是消息的类别,不同的消息类别处理不同;另外一个是消息的发送方式。
         从理论上来说,如果用继承的方式来实现这种有两个变化纬度的情况,最后实际的实现类应该是两个纬度上可变数量的乘积那么多个。比如上面的示例,在消息类别的纬度上,目前的可变数量是3个,普通消息、加急消息和特急消息;在消息发送方式的纬度上,目前的可变数量也是3个,站内短消息、Email和手机短消息。这种情况下,如果要实现全的话,那么需要的实现类应该是:3 × 3 = 9个。
         如果要在任何一个纬度上进行扩展,都需要实现另外一个纬度上的可变数量那么多个实现类,这也是为何会感觉扩展起来很困难。而且随着程序规模的加大,会越来越难以扩展和维护。

而桥接模式就是用来解决这种有两个变化纬度的情况下,如何灵活地扩展功能的一个很好的方案。其实,桥接模式主要是把继承改成了使用对象组合,从而把两个纬度分开,让每一个纬度单独去变化,最后通过对象组合的方式,把两个纬度组合起来,每一种组合的方式就相当于原来继承中的一种实现,这样就有效地减少了实际实现的类的个数。

 
提示
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
        

 

从理论上来说,如果用桥接模式的方式来实现这种有两个变化纬度的情况,最后实际的实现类应该是两个纬度上可变数量的和那么多个。同样是上面那个示例,使用桥接模式来实现,实现全的话,最后需要的实现类的数目应该是:3 + 3 = 6个。
         这也从侧面体现了,使用对象组合的方式比继承要来得更灵活。
8:桥接模式的调用顺序示意图
桥接模式的调用顺序如图24.8所示。
图24.8 桥接模式的调用顺序示意图
所谓谁来桥接,就是谁来负责创建抽象部分和实现部分的关系,说得更直白点,就是谁来负责创建Implementor对象,并把它设置到抽象部分的对象中去,这点对于使用桥接模式来说,是十分重要的一点。
大致有如下几种实现方式。
n           由客户端负责创建Implementor对象,并在创建抽象部分对象的时候,把它设置到抽象部分的对象中去,前面的示例采用的就是这个方式。
n           可以在抽象部分对象构建的时候,由抽象部分的对象自己来创建相应的Implementor的对象,当然可以给它传递一些参数,它可以根据参数来选择并创建具体的Implementor对象。
n           可以在Abstraction中选择并创建一个默认的Implementor对象,然后子类可以根据需要改变这个实现。
n           也可以使用抽象工厂或者简单工厂来选择并创建具体的Implementor的对象,抽象部分的类可以通过调用工厂的方法来获取Implementor对象。
n           如果使用IoC/DI容器的话,还可以通过IoC/DI容器来创建具体的Implementor对象,并注入回到Abstraction中。
下面分别给出后面几种实现方式的示例。
1:由抽象部分的对象自己来创建相应的Implementor的对象
         对于这种情况的实现,又分成两种,一种是需要外部传入参数,另一种是不需要外部传入参数。
(1)从外部传递参数比较简单,比如前面的示例,如果用一个type来标识具体采用哪种发送消息的方案,然后在Abstraction的构造方法中,根据type进行创建就可以了。
还是代码示例一下,主要修改Abstraction的构造方法。示例代码如下:
/**
 * 抽象的消息对象
 */
public abstract class AbstractMessage {
    /**
     * 持有一个实现部分的对象
     */
    protected MessageImplementor impl;
    /**
     * 构造方法,传入选择实现部分的类型
     * @param type 传入选择实现部分的类型
     */
    public AbstractMessage(int type){
        if(type==1){
            this.impl = new MessageSMS();
        }else if(type==2){
            this.impl = new MessageEmail();
        }else if(type==3){
            this.impl = new MessageMobile();
        }
    }  
    /**
     * 发送消息,转调实现部分的方法
     * @param message 要发送的消息内容
     * @param toUser 把消息发送的目的人员
     */
    public void sendMessage(String message,String toUser){
        this.impl.send(message, toUser);
    }  
}
(2)对于不需要外部传入参数的情况,那就说明是在Abstraction的实现中,根据具体的参数数据来选择相应的Implementor对象。有可能在Abstraction的构造方法中选择,也有可能在具体的方法中选择。
         比如前面的示例,如果发送的消息长度在100以内则采用手机短消息;长度在100~1000采用站内短消息;长度在1000以上采用E-mail,那么就可以在内部方法中自己判断实现了。
         实现中,大致有如下改变。
n           原来protected的MessageImplementor类型的属性,不需要了,去掉。
n           提供一个protected的方法来获取要使用的实现部分的对象,在这个方法中,根据消息的长度来选择合适的实现对象。
n           构造方法什么都不用做了,也不需要传入参数。
n           在原来使用impl属性的地方,要修改成通过上面那个方法来获取合适的实现对象了,不能直接使用impl属性,否则会没有值。
示例代码如下:
public abstract class AbstractMessage {
    /**
     * 构造方法
     */
    public AbstractMessage(){
        // 现在什么都不做了
    }
    /**
     * 发送消息,转调实现部分的方法
     * @param message 要发送的消息内容
     * @param toUser 把消息发送的目的人员
     */
    public void sendMessage(String message,String toUser){     
        this.getImpl(message).send(message, toUser);
    }
/**
     * 根据消息的长度来选择合适的实现
     * @param message 要发送的消息
     * @return 合适的实现对象
     */
    protected MessageImplementor getImpl(String message) {
        MessageImplementor impl = null;
        if(message == null){
            // 如果没有消息,默认使用站内短消息
            impl = new MessageSMS();
        }else if(message.length()< 100){
            // 如果消息长度在 100 以内,使用手机短消息
            impl = new MessageMobile();
        }else if(message.length()<1000){
            // 如果消息长度在 100~1000 以内,使用站内短消息
            impl = new MessageSMS();
        }else{
            // 如果消息长度在 1000 以上
            impl = new MessageEmail();
        }
        return impl;
    }
}
(3)小结
         对于由抽象部分的对象自己来创建相应的Implementor对象的这种情况,不管是否需要外部传入参数,优点是Implementor对象的创建和切换逻辑;缺点是Abstraction知道所有的具体的Implementor实现,并知道如何选择和创建它们,如果今后要扩展Implementor的实现,就要求同时修改Abstraction的实现,这会很不灵活,使扩展不方便。要求客户使用简单,而且集中控制
2:在Abstraction中创建默认的Implementor对象
         对于这种方式,实现比较简单,直接在Abstraction的构造方法中,创建一个默认的Implementor对象,然后子类根据需要,看是直接使用还是覆盖掉。示例代码如下:
public abstract class AbstractMessage {
    protected MessageImplementor impl;
    /**
     * 构造方法
     */
    public AbstractMessage(){
        // 创建一个默认的实现
        this.impl = new MessageSMS();
    }
    public void sendMessage(String message,String toUser){
        this.impl.send(message, toUser);
    }
}
         这种方式其实还可以使用工厂方法,把创建工作延迟到子类。
3:使用抽象工厂或者是简单工厂
         对于这种方式,根据具体的需要来选择,如果是想要创建一系列实现对象,那就使用抽象工厂;如果是创建单个的实现对象,使用简单工厂就可以了。
         直接在原来创建Implementor对象的地方,直接调用相应的抽象工厂或者是简单工厂来获取相应的Implementor对象。很简单,这个就不去示例了。
         这种方法的优点是Abstraction类不用和任何一个Implementor类直接耦合。
4:使用IoC/DI的方式
         对于这种方式,Abstraction的实现就更简单了,只需要实现注入Implementor对象的方法就可以了,其他的Abstraction就不管了。
IoC/DI容器会负责创建Implementor对象,并设置回到Abstraction对象中,使用IoC/DI的方式,并不会改变Abstraction和Implementor的关系,Abstraction同样需要持有相应的Implementor对象,同样会把功能委托给Implementor对象去实现。
         在Java应用中,对于桥接模式有一个非常典型的例子,就是:应用程序使用JDBC驱动程序进行开发的方式。所谓驱动程序,指的是按照预先约定好的接口来操作计算机系统或者是外围设备的程序。
         先简单地回忆一下使用JDBC进行开发的过程。简单的片段代码示例如下:
        String sql = "具体要操作的sql语句";
        // 1:装载驱动
        Class.forName(" 驱动的名字 ");
        // 2:创建连接
        Connection conn = DriverManager.getConnection(
" 连接数据库服务的 URL", " 用户名 "," 密码 ");
 
        // 3:创建statement或者是preparedStatement
        PreparedStatement pstmt = conn.prepareStatement(sql);
        // 4:执行sql,如果是查询,再获取ResultSet
        ResultSet rs = pstmt.executeQuery(sql);
 
        // 5:循环从ResultSet中把值取出来,封装到数据对象中去
        while (rs.next()) {
            // 取值示意,按名称取值
            String uuid = rs.getString("uuid");
            // 取值示意,按索引取值
            int age = rs.getInt(2);
        }
        //6:关闭
        rs.close();
        pstmt.close();
        conn.close();
         从上面的示例可以看出,我们写的应用程序,是面向JDBC的API开发,这些接口就相当于桥接模式中抽象部分的接口。那么怎样得到这些API呢?是通过DriverManager来得到的。此时的系统结构如图24.9所示。
图24.9 基于JDBC开发的应用程序结构示意图
         那么这些JDBCAPI,谁去实现呢?光有接口,没有实现也不行啊。
         该驱动程序登场了,JDBC的驱动程序实现了JDBC的API,驱动程序就相当于桥接模式中的具体实现部分。而且不同的数据库,由于数据库实现不一样,可执行的sql也不完全一样,因此对于JDBC驱动的实现也是不一样的,也就是不同的数据库会有不同的驱动实现。此时驱动程序的程序结构如图24.10所示。
图24.10 驱动程序实现结构示意图
         有了抽象部分——JDBCAPI和具体实现部分——驱动程序,那么它们如何连接起来呢?就是如何桥接呢?
就是前面提到的DriverManager来把它们桥接起来。从某个侧面来看,DriverManager在这里起到了类似于简单工厂的功能,基于JDBC的应用程序需要使用JDBC的API,如何得到呢?就通过DriverManager来获取相应的对象。
那么此时系统的整体结构如图24.11所示。
图24.11 JDBC的结构示意图
         通过图23.11可以看出,基于JDBC的应用程序,使用JDBC的API,相当于是对数据库操作的抽象扩展,算做桥接模式的抽象部分;而具体的接口实现是由驱动来完成的,驱动就相当于桥接模式的实现部分了。而桥接的方式,不再是让抽象部分持有实现部分,而是采用了类似于工厂的做法,通过DriverManager来把抽象部分和实现部分对接起来,从而实现抽象部分和实现部分解耦。

延伸

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
对于有些朋友会认为,从局部来看,体现了策略模式,比如在上面的结构中删除“JDBC的API和基于JDBC的应用程序”,那么剩下的部分,看起来就是一个策略模式的体现。此时的DriverManager相当于上下文,而各个具体驱动的实现就相当于是具体的策略实现。这个理解也不算错,但是在这里看来,这样理解是比较片面的。
         JDBC的这种架构,把抽象部分和具体部分分离开来,从而使得抽象部分和具体部分都可以独立扩展。对于应用程序而言,只要选用不同的驱动,就可以让程序操作不同的数据库,而无须更改应用程序,从而实现在不同的数据库上移植;对于驱动程序而言,为数据库实现不同的驱动程序,并不会影响应用程序。而且,JDBC的这种架构,还合理地划分了应用程序开发人员和驱动程序开发人员的边界。

 

 
对于这个问题,再次强调一点:对于设计模式,要从整体结构上、本质目标上和思想体现上来把握,而不要从局部、表现和特例实现上来把握。
         使用Java编写程序,一个很重要的原则就是“面向接口编程”,说得准确点应该是“面向抽象编程”,由于在Java开发中,更多地使用接口而非抽象类,因此通常就说成“面向接口编程”了。
接口把具体的实现和使用接口的客户程序分离开来,从而使得具体的实现和使用接口的客户程序可以分别扩展,而不会相互影响。使用接口的程序结构如图24.12所示。
图24.12 使用接口的程序结构示意图
         可能有些朋友会觉得,听起来怎么像是桥接模式的功能呢?没错,如果把桥接模式的抽象部分先稍稍简化一下,暂时不要RefinedAbstraction部分,那么就跟图24.12所示的结构图差不多了。删除RefinedAbstraction后的简化的桥接模式结构示意图如图24.13所示。
图24.13 简化的桥接模式结构示意图
         是不是差不多呢?有朋友可能会觉得还是有很大差异,差异主要在:前面接口的客户程序是直接使用接口对象,不像桥接模式的抽象部分那样是持有具体实现部分的接口,这就导致画出来的结构图一个是依赖,一个是聚合关联。
         请思考它们的本质功能,桥接模式中的抽象部分持有具体实现部分的接口,最终目的是什么?是为了通过调用具体实现部分的接口中的方法来完成一定的功能,这和直接使用接口差不多,只是表现形式有点不一样。再说,前面那个使用接口的客户程序也可以持有相应的接口对象,这样从形式上就一样了。
         也就是说,从某个角度来讲,桥接模式就是对“面向抽象编程”设计原则的扩展。正是通过具体实现的接口,把抽象部分和具体的实现部分分离开来,抽象部分相当于是使用实现部分接口的客户程序,这样抽象部分和实现部分就松散耦合了,从而可以实现相互独立的变化。
         这样一来,几乎可以把所有面向抽象编写的程序,都视作是桥接模式的体现,至少也是简化的桥接模式,就算是广义的桥接吧。而Java编程很强调“面向抽象编程”,因此,广义的桥接,在Java中可以说是无处不在。
         再举个大家最熟悉的例子来示例一下。在Java应用开发中,分层实现是最基本的设计方式,就拿大家最熟悉的三层架构表现层、逻辑层和数据层来说,或许有些朋友对它们称呼的名称不同,但都是同一回事情。
三层的基本关系是表现层调用逻辑层,逻辑层调用数据层。通过什么方式来进行调用呢?当然是接口了,它们的基本结构如图24.14所示。

数据层接口

 
逻辑层接口
表现层
逻辑层
数据层

 

图24.14 基本的三层架构示意图
         通过接口来进行调用,使得表现层和逻辑层分离开来,也就是说表现层的变化不会影响到逻辑层,同理逻辑层的变化也不会影响到表现层。这也是同一套逻辑层和数据层可以同时支持不同的表现层实现的原因,比如支持Swing或Web方式的表现层。
         在逻辑层和数据层之间也是通过接口来调用,同样将逻辑层和数据层分离,使得它们可以独立地扩展。尤其是数据层,可能会有很多的实现方式,比如,数据库实现、文件实现等,即使是数据库实现,又有针对不同数据库的实现,如Oracle、DB2等。
         总之,通过面向抽象编程,三层架构的各层都能够独立地扩展和变化,而不会对其他层产生影响。这正是桥接模式的功能,实现抽象和实现的分离,从而使得它们可以独立地变化。当然三层架构不只是在一个地方使用桥接模式,而是至少在两个地方来使用桥接模式,一个是在表现层和逻辑层之间,一个是在逻辑层和数据层之间。
         下面先来分别看看这两个使用桥接模式地方的程序结构,然后再综合起来看看整体的程序结构。
逻辑层和数据层之间的程序结构。如图24.15所示。
图24.15 逻辑层和数据层的程序结构示意图
         表现层和逻辑层之间的结构示意。如图24.16所示。
图24.16 表现层和逻辑层的结构示意图
         再把逻辑层、数据层和表现层结合起来。结合后的程序结构如图24.17所示。
图24.17 三层结合的结构示意图
         从广义桥接模式的角度来看,平日熟悉的三层架构其实就是在组合使用桥接模式。从这个图还可以看出,桥接模式是可以连续组合使用的,一个桥接模式的实现部分,可以作为下一个桥接模式的抽象部分N层架构,都可以使用桥接模式来组合。以此类推,可以从三层架构扩展到四层、五层,直到
如果从更本质的角度来看,基本上只要是面向抽象编写的Java程序都可以视为是桥接模式的应用,都是让抽象和实现相分离,从而使它们能独立地变化。不过只要分离的目的达到了,叫不叫桥接模式则无所谓了。
桥接模式的优点如下。
n           分离抽象和实现部分
桥接模式分离了抽象部分和实现部分,从而极大地提高了系统的灵活性。让抽象部分和实现部分独立开来,分别定义接口,这有助于对系统进行分层,从而产生更好的结构化的系统。对于系统的高层部分,只需要知道抽象部分和实现部分的接口就可以了。
n           更好的扩展性
由于桥接模式把抽象部分和实现部分分离开了,而且分别定义接口,这就使得抽象部分和实现部分可以分别独立地扩展,而不会相互影响,从而大大地提高了系统的可扩展性。
n           可动态地切换实现
由于桥接模式把抽象部分和实现部分分离开了,所以在实现桥接的时候,就可以实现动态的选择和使用具体的实现。也就是说一个实现不再是固定的绑定在一个抽象接口上了,可以实现运行期间动态地切换。
n           可减少子类的个数
根据前面的讲述,对于有两个变化纬度的情况,如果采用继承的实现方式,大约需要两个纬度上的可变化数量的乘积个子类;而采用桥接模式来实现,大约需要两个纬度上的可变化数量的和个子类。可以明显地减少子类的个数。

         桥接模式的本质:分离抽象和实现

 
1:桥接模式的本质

 

        
桥接模式最重要的工作就是分离抽象部分和实现部分,这是解决问题的关键。只有把抽象部分和实现部分分离开了,才能够让它们独立地变化;只有抽象部分和实现可地以独立的变化,系统才会有更好的可扩展性和可维护性。
         还有其他的好处,比如,可以动态地切换实现、可以减少子类个数等。都是把抽象部分和实现部分分离过以后,带来的。如果不把抽象部分和实现部分分离开,那一切就无从谈起。所以综合来说,桥接模式的本质在于“分离抽象和实现”。
2对设计原则的体现
(1)桥接模式很好地实现了开闭原则。
         通常应用桥接模式的地方,抽象部分和实现部分都是可变化的,也就是应用会有两个变化纬度,桥接模式就是找到这两个变化,并分别封装起来,从而合理地实现OCP。
         在使用桥接模式的时候,通常情况下,顶层的Abstraction和Implementor是不变的,而具体的Implementor的实现是可变的。由于Abstraction是通过接口来操作具体的实现,因此具体的Implementor的实现是可以扩展的,根据需要可以有多个具体的实现。
         同样地,RefinedAbstraction也是可变的,它继承并扩展Abstraction,通常在RefinedAbstraction的实现中,会调用Abstraction中的方法,通过组合使用来完成更多的功能,这些功能常常是与具体业务有关系的。
(2)桥接模式还很好地体现了:多用对象组合,少用对象继承。
         在前面的示例中,如果使用对象继承来扩展功能,不但让对象之间有很强的耦合性,而且会需要很多的子类才能够完成相应的功能,前面已经讲述过了,需要两个纬度上的可变化数量的乘积个子类。
         而采用对象的组合,松散了对象之间的耦合性,不但使每个对象变得简单和可维护,还大大减少了子类的个数,根据前面的讲述,大约需要两个纬度上的可变化数量的和这么多个子类。
3:何时选用桥接模式
建议在以下情况中选用桥接模式。
n           如果你不希望在抽象部分和实现部分采用固定的绑定关系,可以采用桥接模式,来把抽象部分和实现部分分开,然后在程序运行期间来动态地设置抽象部分需要用到的具体的实现,还可以动态地切换具体的实现。
n           如果出现抽象部分和实现部分都能够扩展的情况,可以采用桥接模式,让抽象部分和实现部分独立地变化,从而灵活地进行单独扩展,而不是搅在一起,扩展一边就会影响到另一边。
n           如果希望实现部分的修改不会对客户产生影响,可以采用桥接模式。由于客户是面向抽象的接口在运行,实现部分的修改可以独立于抽象部分,并不会对客户产生影响,也可以说对客户是透明的。
n           如果采用继承的实现方案,会导致产生很多子类,对于这种情况,可以考虑采用桥接模式,分析功能变化的原因,看看是否能分离成不同的纬度,然后通过桥接模式来分离它们,从而减少子类的数目。
n           桥接模式和策略模式
这两个模式有很大的相似之处。
如果把桥接模式的抽象部分简化来看,暂时不去扩展Abstraction,也就是去掉RefinedAbstraction。桥接模式简化后的结构图如图24.13所示。再看看策略模式的结构图,参见图17.1。会发现,这个时候它们的结构都类似图24.18所示。
        24.18  桥接模式和策略模式结构示意图
通过上面的结构图,可以体会到桥接模式和策略模式是如此相似。可以把策略模式的Context当做是使用接口的对象,而Strategy就是某个接口了,具体的策略实现就相当于接口的具体实现。这样看来的话,某些情况下,可以使用桥接模式来模拟实现策略模式的功能。
这两个模式虽然相似,但也还是有区别的。最主要的是模式的目的不一样,策略模式的目的是封装一系列的算法,使得这些算法可以相互替换;而桥接模式的目的是分离抽象部分和实现部分,使得它们可以独立地变化。
n           桥接模式和状态模式
由于从模式结构上看,状态模式和策略模式是一样的,因此这两个模式的关系也基本上类似于桥接模式和策略模式的关系。
只不过状态模式的目的是封装状态对应的行为,并在内部状态改变的时候改变对象的行为。
n           桥接模式和模板方法模式
这两个模式有相似之处。
虽然标准的模板方法模式是采用继承来实现的,但是模板方法也可以通过回调接口的方式来实现。如果把接口的实现独立出去,那就类似于模板方法通过接口去调用具体的实现方法了,这样的结构就和简化的桥接模式类似了。
可以使用桥接模式来模拟实现模板方法模式的功能。如果在实现Abstraction对象的时候,在其中定义方法,方法中就是某个固定的算法骨架,也就是说这个方法就相当于模板方法。在模板方法模式中,是把不能确定实现的步骤延迟到子类去实现;现在在桥接模式中,把不能确定实现的步骤委托给具体实现部分去完成,通过回调实现部分的接口,来完成算法骨架中的某些步骤。这样一来,就可以实现使用桥接模式来模拟实现模板方法模式的功能。

另外,这里只是说从实现具体的业务功能上,桥接模式可以模拟实现模板方法模式能实现的功能,并不是说桥接模式和模板方法模式就变成一样的,或者是桥接模式就可以替换模板方法模式了。要注意它们本身的功能、目的、本质思想都是不一样的。

 
使用桥接模式来模拟实现模板方法模式的功能,还有一个潜在的好处,就是模板方法也可以很方便地扩展和变化。在标准的模板方法中,一个问题就是当模板发生变化的时候,所有的子类都要变化,非常不方便。而使用桥接模式来实现类似的功能,就没有这个问题。

 

注意

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

 

 
 
 
 

n           桥接模式和抽象工厂模式
这两个模式可以组合使用。
桥接模式中,抽象部分需要获取相应的实现部分的接口对象,那么谁来创建实现部分的具体实现对象呢?这就是抽象工厂模式派上用场的地方。也就是使用抽象工厂模式来创建和配置一个特定的具体的实现对象。
事实上,抽象工厂主要是用来创建一系列对象的,如果创建的对象很少,或者是很简单,还可以采用简单工厂,也能达到同样的效果,但是会比抽象工厂来得简单。
n           桥接模式和适配器模式
这两个模式可以组合使用。
这两个模式功能是完全不一样的,适配器模式的功能主要是用来帮助无关的类协同工作,重点在解决原本由于接口不兼容而不能一起工作的那些类,使得它们可以一起工作。而桥接模式则重点在分离抽象部分和实现部分。
所以在使用上,通常在系统设计完成以后,才会考虑使用适配器模式;而桥接模式。是在系统开始的时候就要考虑使用。
n               虽然功能上不一样,这两个模式还是可以组合使用的,比如,已有实现部分的接口,但是有些不太适应现在新的功能对接口的需要,完全抛弃吧,有些功能还用得上,该怎么办呢?那就使用适配器来进行适配,使得旧的接口能够适应新的功能的需要。
 
评论 9
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值