【白话设计模式九】桥接模式(Bridge)

#0 系列目录#

• 白话设计模式
• 工厂模式
• 单例模式
• 【白话设计模式一】简单工厂模式(Simple Factory)
• 【白话设计模式二】外观模式(Facade)
• 【白话设计模式三】适配器模式(Adapter)
• 【白话设计模式四】单例模式(Singleton)
• 【白话设计模式五】工厂方法模式(Factory Method)
• 【白话设计模式六】抽象工厂模式(Abstract Factory)
• 【白话设计模式七】策略模式(Strategy)
• 【白话设计模式八】命令模式(Command)
• 【白话设计模式九】桥接模式(Bridge)
• 【白话设计模式十】装饰模式(Decorator)
• 【白话设计模式十一】生成器模式(Builder)
• 【白话设计模式十二】原型模式(Prototype)
• 【白话设计模式十三】中介者模式(Mediator)
• 【白话设计模式十四】代理模式(Proxy)
• 【白话设计模式十五】观察者模式(Observer)
• 【白话设计模式十六】迭代器模式(Iterator)
• 【白话设计模式十七】组合模式(Composite)
• 【白话设计模式十八】模板方法模式(Template Method)
• 【白话设计模式十九】状态模式(State)
• 【白话设计模式二十】备忘录模式(Memento)
• 【白话设计模式二十一】享元模式(Flyweight)
• 【白话设计模式二十二】解释器模式(Interpreter)
• 【白话设计模式二十三】职责链模式(Chain of Responsibility)
• 【白话设计模式二十四】访问者模式(Visitor)
• 【白话设计模式二十五】临别总结：设计模式与7大原则

#1 场景问题# ##1.1 发送提示消息## 考虑这样一个实际的业务功能：发送提示消息。基本上全部带业务流程处理的系统都会有这样的功能，好比某人有新的工做了，须要发送一条消息提示他。

从业务上看，消息又分红普通消息、加急消息和特急消息多种，不一样的消息类型，业务功能处理是不同的，好比加急消息是在消息上添加加急，而特急消息除了添加特急外，还会作一条催促的记录，多久不完成会继续催促。从发送消息的手段上看，又有系统内短消息、手机短消息、邮件等等。

如今要实现这样的发送提示消息的功能，该如何实现呢？

##1.2 不用模式的解决方案##

1. 实现简化版本

先考虑实现一个简单点的版本，好比：消息先只是实现发送普通消息，发送的方式呢，先实现系统内短消息和邮件。其它的功能，等这个版本完成事后，再继续添加，这样先把问题简单化，实现起来会容易一点。

（1）因为发送普通消息会有两种不一样的实现方式，为了让外部能统一操做，所以，把消息设计成接口，而后由两个不一样的实现类，分别实现系统内短消息方式和邮件发送消息的方式。此时系统结构如图1所示：

（2）先来看看消息的统一接口，示例代码以下：

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

（3）再来分别看看两种实现方式，这里只是为了示意，并不会真的去发送Email和站内短消息，先看站内短消息的方式，示例代码以下：

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

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

2. 实现发送加急消息

上面的实现，看起来很简单，对不对。接下来，添加发送加急消息的功能，也有两种发送的方式，一样是站内短消息和Email的方式。

加急消息的实现跟普通消息不一样，加急消息会自动在消息上添加加急，而后再发送消息；另外加急消息会提供监控的方法，让客户端能够随时经过这个方法来了解对于加急消息处理的进度，好比：相应的人员是否接收到这个信息，相应的工做是否已经开展等等。所以加急消息须要扩展出一个新的接口，除了基本的发送消息的功能，还须要添加监控的功能，这个时候，系统的结构如图2所示：

（1）先看看扩展出来的加急消息的接口，示例代码以下：

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

（2）相应的实现方式仍是发送站内短消息和Email两种，一样须要两个实现类来分别实现这两种方式，先看站内短消息的方式，示例代码以下：

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;  
    }     
} 

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.3 有何问题## 上面这样实现，好像也能知足基本的功能要求，但是这么实现好很差呢？有没有什么问题呢？

我们继续向下来添加功能实现，为了简洁，就再也不去进行代码示意了，经过实现的结构示意图就能够看出实现上的问题。

1. 继续添加特急消息的处理

特急消息不须要查看处理进程，只要没有完成，就直接催促，也就是说，对于特急消息，在普通消息的处理基础上，须要添加催促的功能。而特急消息、还有催促的发送方式，相应的实现方式仍是发送站内短消息和Email两种，此时系统的结构如图3所示：

仔细观察上面的系统结构示意图，会发现一个很明显的问题，那就是：经过这种继承的方式来扩展消息处理，会很是不方便。

你看，实现加急消息处理的时候，必须实现站内短消息和Email两种处理方式，由于业务处理可能不一样；在实现特急消息处理的时候，又必须实现站内短消息和Email这两种处理方式。

这意味着，之后每次扩展一下消息处理，都必需要实现这两种处理方式，是否是很痛苦，这还不算完，若是要添加新的实现方式呢？继续向下看吧。

2. 继续添加发送手机消息的处理方式

若是看到上面的实现，你还感受问题不是很大的话，继续完成功能，添加发送手机消息的处理方式。

仔细观察如今的实现，若是要添加一种新的发送消息的方式，是须要在每一种抽象的具体实现里面，都要添加发送手机消息的处理的。也就是说：发送普通消息、加急消息和特急消息的处理，均可以经过手机来发送。这就意味着，须要添加三个实现。此时系统结构如图4所示：

3. 小结一下出现的问题

采用经过继承来扩展的实现方式，有个明显的缺点：扩展消息的种类不太容易，不一样种类的消息具备不一样的业务，也就是有不一样的实现，在这种状况下，每一个种类的消息，须要实现全部不一样的消息发送方式。

更可怕的是，若是要新加入一种消息的发送方式，那么会要求全部的消息种类，都要加入这种新的发送方式的实现。

要是考虑业务功能上再扩展一下呢？好比：要求实现群发消息，也就是一次能够发送多条消息，这就意味着不少地方都得修改，太恐怖了。

那么究竟该如何实现才能既实现功能，又能灵活的扩展呢？

#2 解决方案# ##2.1 桥接模式来解决## 用来解决上述问题的一个合理的解决方案，就是使用桥接模式。那么什么是桥接模式呢？

1. 桥接模式定义

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

2. 应用桥接模式来解决的思路

仔细分析上面的示例，根据示例的功能要求，示例的变化具备两个纬度，一个纬度是抽象的消息这边，包括普通消息、加急消息和特急消息，这几个抽象的消息自己就具备必定的关系，加急消息和特急消息会扩展普通消息；另外一个纬度在具体的消息发送方式上，包括站内短消息、Email和手机短信息，这几个方式是平等的，可被切换的方式。这两个纬度一共能够组合出9种不一样的可能性来，它们的关系以下图5所示：

如今出现问题的根本缘由，就在于消息的抽象和实现是混杂在一块儿的，这就致使了，一个纬度的变化，会引发另外一个纬度进行相应的变化，从而使得程序扩展起来很是困难。

要想解决这个问题，就必须把这两个纬度分开，也就是将抽象部分和实现部分分开，让它们相互独立，这样就能够实现独立的变化，使扩展变得简单。

桥接模式经过引入实现的接口，把实现部分从系统中分离出去；那么，抽象这边如何使用具体的实现呢？确定是面向实现的接口来编程了，为了让抽象这边可以很方便的与实现结合起来，把顶层的抽象接口改为抽象类，在里面持有一个具体的实现部分的实例。

这样一来，对于须要发送消息的客户端而言，就只须要建立相应的消息对象，而后调用这个消息对象的方法就能够了，这个消息对象会调用持有的真正的消息发送方式来把消息发送出去。也就是说客户端只是想要发送消息而已，并不想关心具体如何发送。

##2.2 模式结构和说明##

Abstraction：抽象部分的接口。一般在这个对象里面，要维护一个实现部分的对象引用，在抽象对象里面的方法，须要调用实现部分的对象来完成。这个对象里面的方法，一般都是跟具体的业务相关的方法。

RefinedAbstraction：扩展抽象部分的接口，一般在这些对象里面，定义跟实际业务相关的方法，这些方法的实现一般会使用Abstraction中定义的方法，也可能须要调用实现部分的对象来完成。

Implementor：定义实现部分的接口，这个接口不用和Abstraction里面的方法一致，一般是由Implementor接口提供基本的操做，而Abstraction里面定义的是基于这些基本操做的业务方法，也就是说Abstraction定义了基于这些基本操做的较高层次的操做。

ConcreteImplementor：真正实现Implementor接口的对象。

##2.3 桥接模式示例代码##

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中定义的方法来完成更多的功能  
    }  
}

##2.4 使用桥接模式重写示例## 学习了桥接模式的基础知识事后，该来使用桥接模式重写前面的示例了。经过示例，来看看使用桥接模式来实现一样的功能，是否能解决“既能方便的实现功能，又能有很好的扩展性”的问题。

要使用桥接模式来从新实现前面的示例，首要任务就是要把抽象部分和实现部分分离出来，分析要实现的功能，抽象部分就是各个消息的类型所对应的功能，而实现部分就是各类发送消息的方式。

其次要按照桥接模式的结构，给抽象部分和实现部分分别定义接口，而后分别实现它们就能够了。

1. 从简单功能开始

从相对简单的功能开始，先实现普通消息和加急消息的功能，发送方式先实现站内短消息和Email这两种。

使用桥接模式来实现这些功能的程序结构如图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);  
    }  
}

/** 
 * 以Email的方式发送消息 
 */  
public class MessageEmail implements MessageImplementor{  
    public void send(String message, String toUser) {  
        System.out.println("使用Email的方式，发送消息'"+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("请喝一杯茶", "小李");  
    }  
}

运行结果以下：

使用站内短消息的方式，发送消息'请喝一杯茶'给小李  
使用站内短消息的方式，发送消息'加急：请喝一杯茶'给小李  
使用站内短消息的方式，发送消息'特急：请喝一杯茶'给小李  
使用手机短消息的方式，发送消息'请喝一杯茶'给小李  
使用手机短消息的方式，发送消息'加急：请喝一杯茶'给小李  
使用手机短消息的方式，发送消息'特急：请喝一杯茶'给小李

#3 模式讲解# ##3.1 认识桥接模式##

1. 什么是桥接

在桥接模式里面，不太好理解的就是桥接的概念，什么是桥接？为什么须要桥接？如何桥接？把这些问题搞清楚了，也就基本明白桥接的含义了。

一个一个来，先看什么是桥接？所谓桥接，通俗点说就是在不一样的东西之间搭一个桥，让他们可以链接起来，能够相互通信和使用。那么在桥接模式中究竟是给什么东西来搭桥呢？就是为被分离了的抽象部分和实现部分来搭桥，好比前面示例中抽象的消息和具体消息发送之间搭个桥。

可是这里要注意一个问题：在桥接模式中的桥接是单向的，也就是只能是抽象部分的对象去使用具体实现部分的对象，而不能反过来，也就是个单向桥。

2. 为什么须要桥接

为了达到让抽象部分和实现部分均可以独立变化的目的，在桥接模式中，是把抽象部分和实现部分分离开来的，虽然从程序结构上是分开了，可是在抽象部分实现的时候，仍是须要使用具体的实现的，这可怎么办呢？抽象部分如何才能调用到具体实现部分的功能呢？很简单，搭个桥不就能够了，搭个桥，让抽象部分经过这个桥就能够调用到实现部分的功能了，所以须要桥接。

3. 如何桥接

这个理解上也很简单，只要让抽象部分拥有实现部分的接口对象，这就桥接上了，在抽象部分就能够经过这个接口来调用具体实现部分的功能。也就是说，桥接在程序上就体现成了在抽象部分拥有实现部分的接口对象，维护桥接就是维护这个关系。

4. 独立变化

桥接模式的意图：使得抽象和实现能够独立变化，均可以分别扩充。也就是说抽象部分和实现部分是一种很是松散的关系，从某个角度来说，抽象部分和实现部分是能够彻底分开的，独立的，抽象部分不过是一个使用实现部分对外接口的程序罢了。

若是这么看桥接模式的话，就相似于策略模式了，抽象部分须要根据某个策略，来选择真实的实现，也就是说桥接模式的抽象部分至关于策略模式的上下文。更原始的就直接相似于面向接口编程，经过接口分离的两个部分而已。可是别忘了，桥接模式的抽象部分，是能够继续扩展和变化的，而策略模式只有上下文，是不存在所谓抽象部分的。

那抽象和实现为什么还要组合在一块儿呢？缘由是在抽象部分和实现部分仍是存在内部联系的，抽象部分的实现一般是须要调用实现部分的功能来实现的。

5. 动态变换功能

因为桥接模式中的抽象部分和实现部分是彻底分离的，所以能够在运行时动态组合具体的真实实现，从而达到动态变换功能的目的。

从另一个角度看，抽象部分和实现部分没有固定的绑定关系了，所以同一个真实实现能够被不一样的抽象对象使用，反过来，同一个抽象也能够有多个不一样的实现。就像前面示例的那样，好比：站内短消息的实现功能，能够被普通消息、加急消息或是特急消息等不一样的消息对象使用；反过来，某个消息具体的发送方式，能够是站内短消息，或者是Email，也能够是手机短消息等具体的发送方式。

6. 退化的桥接模式

若是Implementor仅有一个实现，那么就没有必要建立Implementor接口了，这是一种桥接模式退化的状况。这个时候Abstraction和Implementor是一对一的关系，虽然如此，也仍是要保持它们的分离状态，这样的话，它们才不会相互影响，才能够分别扩展。

也就是说，就算不要Implementor接口了，也要保持Abstraction和Implementor是分离的，模式的分离机制仍然是很是有用的。

7. 桥接模式和继承

继承是扩展对象功能的一种常见手段，一般状况下，继承扩展的功能变化纬度都是一纬的，也就是变化的因素只有一类。

对于出现变化因素有两类的，也就是有两个变化纬度的状况，继承实现就会比较痛苦。好比上面的示例，就有两个变化纬度，一个是消息的类别，不一样的消息类别处理不一样；另一个是消息的发送方式。

从理论上来讲，若是用继承的方式来实现这种有两个变化纬度的状况，最后实际的实现类应该是两个纬度上可变数量的乘积那么多个。好比上面的示例，在消息类别的纬度上，目前的可变数量是3个，普通消息、加急消息和特急消息；在消息发送方式的纬度上，目前的可变数量也是3个，站内短消息、Email和手机短消息。这种状况下，若是要实现全的话，那么须要的实现类应该是：3 X 3 = 9个。

若是要在任何一个纬度上进行扩展，都须要实现另一个纬度上的可变数量那么多个实现类，这也是为什么会感到扩展起来很困难。并且随着程序规模的加大，会愈来愈难以扩展和维护。

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

从理论上来讲，若是用桥接模式的方式来实现这种有两个变化纬度的状况，最后实际的实现类应该是两个纬度上可变数量的和那么多个。一样是上面那个示例，使用桥接模式来实现，实现全的话，最后须要的实现类的数目应该是：3 + 3 = 6个。

这也从侧面体现了，使用对象组合的方式比继承要来得更灵活。

8. 桥接模式的调用顺序示意图

##3.2 谁来桥接## 所谓谁来桥接，就是谁来负责建立抽象部分和实现部分的关系，说得更直白点，就是谁来负责建立Implementor的对象，并把它设置到抽象部分的对象里面去，这点对于使用桥接模式来讲，是十分重要的一点。

大体有以下几种实现方式：

由客户端负责建立Implementor的对象，并在建立抽象部分的对象的时候，把它设置到抽象部分的对象里面去，前面的示例采用的就是这个方式

能够在抽象部分的对象构建的时候，由抽象部分的对象本身来建立相应的Implementor的对象，固然能够给它传递一些参数，它能够根据参数来选择并建立具体的Implementor的对象

能够在Abstraction中选择并建立一个缺省的Implementor的对象，而后子类能够根据须要改变这个实现

也可使用抽象工厂或者简单工厂来选择并建立具体的Implementor的对象，抽象部分的类能够经过调用工厂的方法来获取Implementor的对象

若是使用IoC/DI容器的话，还能够经过IoC/DI容器来建立具体的Implementor的对象，并注入回到Abstraction中

1. 由抽象部分的对象本身来建立相应的Implementor的对象

对于这种状况的实现，又分红两种，一种是须要外部传入参数，一种是不须要外部传入参数。

（1）从外面传递参数比较简单，好比前面的示例，若是用一个type来标识具体采用哪一种发送消息的方案，而后在Abstraction的构造方法中，根据type进行建立就行了。

/** 
 * 抽象的消息对象 
 */  
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以上采用Email，那么就能够在内部方法中本身判断实现了。

实现中，大体有以下改变：

原来protected的MessageImplementor类型的属性，不须要了，去掉

提供一个protected的方法来获取要使用的实现部分的对象，在这个方法里面，根据消息的长度来选择合适的实现对象

构造方法什么都不用作了，也不须要传入参数

在原来使用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对象去实现。

##3.3 典型例子-JDBC## 在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来获得的。此时的系统结构如图9所示：

那么这些JDBC的API，谁去实现呢？光有接口，没有实现也不行啊。

该驱动程序登场了，JDBC的驱动程序实现了JDBC的API，驱动程序就至关于桥接模式中的具体实现部分。并且不一样的数据库，因为数据库实现不同，可执行的Sql也不彻底同样，所以对于JDBC驱动的实现也是不同的，也就是不一样的数据库会有不一样的驱动实现。此时驱动程序这边的程序结构如图10所示：

有了抽象部分——JDBC的API，有了具体实现部分——驱动程序，那么它们如何链接起来呢？就是如何桥接呢？

就是前面提到的DriverManager来把它们桥接起来，从某个侧面来看，DriverManager在这里起到了相似于简单工厂的功能，基于JDBC的应用程序须要使用JDBC的API，如何获得呢？就经过DriverManager来获取相应的对象。

那么此时系统的总体结构如图11所示：

经过上图能够看出，基于JDBC的应用程序，使用JDBC的API，至关因而对数据库操做的抽象的扩展，算做桥接模式的抽象部分；而具体的接口实现是由驱动来完成的，驱动这边天然就至关于桥接模式的实现部分了。而桥接的方式，再也不是让抽象部分持有实现部分，而是采用了相似于工厂的作法，经过DriverManager来把抽象部分和实现部分对接起来，从而实现抽象部分和实现部分解耦。

JDBC的这种架构，把抽象和具体分离开来，从而使得抽象和具体部分均可以独立扩展。对于应用程序而言，只要选用不一样的驱动，就可让程序操做不一样的数据库，而无需更改应用程序，从而实如今不一样的数据库上移植；对于驱动程序而言，为数据库实现不一样的驱动程序，并不会影响应用程序。并且，JDBC的这种架构，还合理的划分了应用程序开发人员和驱动程序开发人员的边界。

对于有些朋友会认为，从局部来看，体现了策略模式，好比在上面的结构中去掉“JDBC的API和基于JDBC的应用程序”这边，那么剩下的部分，看起来就是一个策略模式的体现。此时的DriverManager就至关于上下文，而各个具体驱动的实现就至关因而具体的策略实现，这个理解也不算错，可是在这里看来，这么理解是比较片面的。

对于这个问题，再次强调一点：对于设计模式，要从总体结构上、从本质目标上、从思想体现上来把握，而不要从局部、从表现、从特例实现上来把握。

##3.4 广义桥接-Java中无处不桥接## 使用Java编写程序，一个很重要的原则就是“面向接口编程”，说得准确点应该是“面向抽象编程”，因为在Java开发中，更多的使用接口而非抽象类，所以一般就说成“面向接口编程”了。

接口把具体的实现和使用接口的客户程序分离开来，从而使得具体的实现和使用接口的客户程序能够分别扩展，而不会相互影响。使用接口的程序结构如图12所示：

可能有些朋友会以为，听起来怎么像是桥接模式的功能呢？没错，若是把桥接模式的抽象部分先稍稍简化一下，暂时不要RefinedAbstraction部分，那么就跟上面的结构图差很少了。去掉RefinedAbstraction后的简化的桥接模式结构示意图如图13所示：

是否是差很少呢？有朋友可能会以为仍是有很大差别，差别主要在：前面接口的客户程序是直接使用接口对象，不像桥接模式的抽象部分那样，是持有具体实现部分的接口，这就致使画出来的结构图，一个是依赖，一个是聚合关联。

请思考它们的本质功能，桥接模式中的抽象部分持有具体实现部分的接口，最终目的是什么，还不是须要经过调用具体实现部分的接口中的方法，来完成必定的功能，这跟直接使用接口没有什么不一样，只是表现形式有点不同。再说，前面那个使用接口的客户程序也能够持有相应的接口对象，这样从形式上就同样了。

也就是说，从某个角度来说，桥接模式不过就是对“面向抽象编程”这个设计原则的扩展。正是经过具体实现的接口，把抽象部分和具体的实现分离开来，抽象部分至关因而使用实现部分接口的客户程序，这样抽象部分和实现部分就松散耦合了，从而能够实现相互独立的变化。

这样一来，几乎能够把全部面向抽象编写的程序，都视做是桥接模式的体现，至少算是简化的桥接模式，就算是广义的桥接吧。而Java编程很强调“面向抽象编程”，所以，广义的桥接，在Java中能够说是无处不在。

再举个你们最熟悉的例子来示例一下。在Java应用开发中，分层实现算是最基本的设计方式了吧，就拿你们最熟的三层架构来讲，表现层、逻辑层和数据层，或许有些朋友对它们称呼的名称不一样，但都是同一回事情。

三层的基本关系是表现层调用逻辑层，逻辑层调用数据层，经过什么来进行调用呢？固然是接口了，它们的基本结构如图14所示：

经过接口来进行调用，使得表现层和逻辑层分离开来，也就是说表现层的变化，不会影响到逻辑层，同理逻辑层的变化不会影响到表现层。这也是同一套逻辑层和数据层，就可以同时支持不一样的表现层实现的缘由，好比支持Swing或Web方式的表现层。

在逻辑层和数据层之间也是经过接口来调用，一样使得逻辑层和数据层分离开，使得它们能够独立的扩展。尤为是数据层，可能会有不少的实现方式，好比：数据库实现、文件实现等，就算是数据库实现，又有针对不一样数据库的实现，如Oracle、DB2等等。

总之，经过面向抽象编程，三层架构的各层都可以独立的扩展和变化，而不会对其它层次产生影响。这正好是桥接模式的功能，实现抽象和实现的分离，从而使得它们能够独立的变化。固然三层架构不仅是在一个地方使用桥接模式，而是至少在两个地方来使用了桥接模式，一个在表现层和逻辑层之间，一个在逻辑层和数据层之间。

下面先分别看看这两个使用桥接模式的地方的程序结构，而后再综合起来看看总体的程序结构。先看看逻辑层和数据层之间的程序结构，如图15所示：

再看看表现层和逻辑层之间的结构示意，如图16所示：

而后再把它们结合起来，看看结合后的程序结构，如图17所示：

从广义桥接模式的角度来看，平日熟悉的三层架构其实就是在组合使用桥接模式。从这个图还能够看出，桥接模式是能够连续组合使用的，一个桥接模式的实现部分，能够做为下一个桥接模式的抽象部分。如此类推，能够从三层架构扩展到四层、五层、直到N层架构，均可以使用桥接模式来组合。

若是从更本质的角度来看，基本上只要是面向抽象编写的Java程序，均可以视为是桥接模式的应用，都是让抽象和实现相分离，从而使它们能独立的变化。不过只要分离的目的达到了，叫不叫桥接模式就无所谓了。

##3.5 桥接模式的优缺点##

1. 分离抽象和实现部分

桥接模式分离了抽象和实现部分，从而极大地提升了系统的灵活性。让抽象部分和实现部分独立开来，分别定义接口，这有助于对系统进行分层，从而产生更好的结构化的系统。对于系统的高层部分，只须要知道抽象部分和实现部分的接口就能够了。

2. 更好的扩展性

因为桥接模式把抽象和实现部分分离开了，并且分别定义接口，这就使得抽象部分和实现部分能够分别独立的扩展，而不会相互影响，从而大大的提升了系统的可扩展性。 可动态切换实现

因为桥接模式把抽象和实现部分分离开了，那么在实现桥接的时候，就能够实现动态的选择和使用具体的实现，也就是说一个实现再也不是固定的绑定在一个抽象接口上了，能够实现运行期间动态的切换实现。

3. 可减小子类的个数

根据前面的讲述，对于有两个变化纬度的状况，若是采用继承的实现方式，大约须要两个纬度上的可变化数量的乘积个子类；而采用桥接模式来实现的话，大约须要两个纬度上的可变化数量的和个子类。能够明显地减小子类的个数。

##3.6 思考桥接模式##

1. 桥接模式的本质

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

桥接模式最重要的工做就是分离抽象部分和实现部分，这是解决问题的关键。只有把抽象和实现分离开了，才可以让它们能够独立的变化；只有抽象和实现能够独立的变化，系统才会有更好的可扩展性、可维护性。

至于其它的好处，好比：能够动态切换实现、能够减小子类个数等。都是把抽象部分和实现部分分离事后，带来的，若是不把抽象部分和实现部分分离开，那就一切免谈了。因此综合来讲，桥接模式的本质在于“分离抽象和实现”。

2. 对设计原则的体现

（1）桥接模式很好的实现了开闭原则

一般应用桥接模式的地方，抽象部分和实现部分都是可变化的，也就是应用会有两个变化纬度，桥接模式就是找到这两个变化，并分别封装起来，从而合理的实现OCP。

在使用桥接模式的时候，一般状况下，顶层的Abstraction和Implementor是不变的，而具体的Implementor的实现，是可变的，因为Abstraction是经过接口来操做具体的实现，所以具体的Implementor的实现是能够扩展的，根据须要能够有多个具体的实现。

一样的，RefinedAbstraction也是可变的，它继承并扩展Abstraction，一般在RefinedAbstraction的实现里面，会调用Abstraction中的方法，经过组合使用来完成更多的功能，这些功能经常是与具体业务有关系的功能。

（2）桥接模式还很好的体现了：多用对象组合，少用对象继承

在前面的示例中，若是使用对象继承来扩展功能，不但让对象之间有很强的耦合性，并且会须要不少的子类才能完成相应的功能，前面已经讲述过了，须要两个纬度上的可变化数量的乘积个子类。

而采用对象的组合，松散了对象之间的耦合性，不但使每一个对象变得简单和可维护，还大大减小了子类的个数，根据前面的讲述，大约须要两个纬度上的可变化数量的和这么多个子类。

3. 什么时候选用桥接模式

建议在以下状况中，选用桥接模式：

若是你不但愿在抽象和实现部分采用固定的绑定关系，能够采用桥接模式，来把抽象和实现部分分开，而后在程序运行期间来动态的设置抽象部分须要用到的具体的实现，还能够动态切换具体的实现。

若是出现抽象部分和实现部分都应该能够扩展的状况，能够采用桥接模式，让抽象部分和实现部分能够独立的变化，从而能够灵活的进行单独扩展，而不是搅在一块儿，扩展一边会影响到另外一边。

若是但愿实现部分的修改，不会对客户产生影响，能够采用桥接模式，客户是面向抽象的接口在运行，实现部分的修改，能够独立于抽象部分，也就不会对客户产生影响了，也能够说对客户是透明的。

若是采用继承的实现方案，会致使产生不少子类，对于这种状况，能够考虑采用桥接模式，分析功能变化的缘由，看看是否能分离成不一样的纬度，而后经过桥接模式来分离它们，从而减小子类的数目。

##3.7 相关模式##

1. 桥接模式和策略模式

这两个模式有很大的类似之处。

若是把桥接模式的抽象部分简化来看，若是暂时不去扩展Abstraction，也就是去掉RefinedAbstraction。桥接模式简化事后的结构图参见图13。再看策略模式的结构图参见图17.1。会发现，这个时候它们的结构都相似如图18所示：

经过上面的结构图，能够体会到桥接模式和策略模式是如此类似。能够把策略模式的Context视作是使用接口的对象，而Strategy就是某个接口了，具体的策略实现那就至关于接口的具体实现。这样看来的话，某些状况下，可使用桥接模式来模拟实现策略模式的功能。

这两个模式虽然类似，也仍是有区别的。最主要的是模式的目的不同，策略模式的目的是封装一系列的算法，使得这些算法能够相互替换；而桥接模式的目的是分离抽象和实现部分，使得它们能够独立的变化。

2. 桥接模式和状态模式

因为从模式结构上看，状态模式和策略模式是同样的，这两个模式的关系也基本上相似于桥接模式和策略模式的关系。

只不过状态模式的目的是封装状态对应的行为，并在内部状态改变的时候改变对象的行为。

3. 桥接模式和模板方法模式

这两个模式有类似之处。

虽然标准的模板方法模式是采用继承来实现的，可是模板方法也能够经过回调接口的方式来实现，若是把接口的实现独立出去，那就相似于模板方法经过接口去调用具体的实现方法了。这样的结构就和简化的桥接模式相似了。

可使用桥接模式来模拟实现模板方法模式的功能。若是在实现Abstraction对象的时候，在里面定义方法，方法里面就是某个固定的算法骨架，也就是说这个方法就至关于模板方法。在模板方法模式里，是把不能肯定实现的步骤延迟到子类去实现；如今在桥接模式里面，把不能肯定实现的步骤委托给具体实现部分去完成，经过回调实现部分的接口，来完成算法骨架中的某些步骤。这样一来，就能够实现使用桥接模式来模拟实现模板方法模式的功能了。

使用桥接模式来模拟实现模板方法模式的功能，还有个潜在的好处，就是模板方法也能够很方便的扩展和变化了。在标准的模板方法里面，一个问题就是当模板发生变化的时候，全部的子类都要变化，很是不方便。而使用桥接模式来实现相似的功能，就没有这个问题了。

另外，这里只是说从实现具体的业务功能上，桥接模式能够模拟实现出模板方法模式能实现的功能，并非说桥接模式和模板方法模式就变成同样的，或者是桥接模式就能够替换掉模板方法模式了。要注意它们自己的功能、目的、本质思想都是不同的。

4. 桥接模式和抽象工厂模式

这两个模式能够组合使用。

桥接模式中，抽象部分须要获取相应的实现部分的接口对象，那么谁来建立实现部分的具体实现对象呢？这就是抽象工厂模式派上用场的地方。也就是使用抽象工厂模式来建立和配置一个特定的具体实现的对象。

事实上，抽象工厂主要是用来建立一系列对象的，若是建立的对象不多，或者是很简单，还能够采用简单工厂，能够达到同样的效果，可是会比抽象工厂来得简单。

5. 桥接模式和适配器模式

这两个模式能够组合使用。

这两个模式功能是彻底不同的，适配器模式的功能主要是用来帮助无关的类协同工做，重点在解决本来因为接口不兼容而不能一块儿工做的那些类，使得它们能够一块儿工做。而桥接模式则重点在分离抽象和实现部分。

因此在使用上，一般在系统设计完成事后，才会考虑使用适配器模式；而桥接模式，是在系统开始的时候就要考虑使用。

虽然功能上不同，这两个模式仍是能够组合使用的，好比：已有实现部分的接口，可是有些不太适应如今新的功能对接口的须要，彻底抛弃吧，有些功能还用得上，该怎么办呢？那就使用适配器来进行适配，使得旧的接口可以适应新的功能的须要。