研磨设计模式 之 桥接模式（Bridge）3——跟着cc学设计系列

24.3  模式讲解

24.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）桥接模式的调用顺序示意图

桥接模式的调用顺序如图24.8所示：

 

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

24.3.2  谁来桥接

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

大致有如下几种实现方式：

• 由客户端负责创建Implementor的对象，并在创建抽象部分的对象的时候，把它设置到抽象部分的对象里面去，前面的示例采用的就是这个方式
• 可以在抽象部分的对象构建的时候，由抽象部分的对象自己来创建相应的Implementor的对象，当然可以给它传递一些参数，它可以根据参数来选择并创建具体的Implementor的对象
• 可以在Abstraction中选择并创建一个缺省的Implementor的对象，然后子类可以根据需要改变这个实现
• 也可以使用抽象工厂或者简单工厂来选择并创建具体的Implementor的对象，抽象部分的类可以通过调用工厂的方法来获取Implementor的对象
• 如果使用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以上采用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对象去实现。

24.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来得到的。此时的系统结构如图24.9所示：

 

图24.9  基于JDBC开发的应用程序结构示意图

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

       该驱动程序登场了，JDBC的驱动程序实现了JDBC的API，驱动程序就相当于桥接模式中的具体实现部分。而且不同的数据库，由于数据库实现不一样，可执行的Sql也不完全一样，因此对于JDBC驱动的实现也是不一样的，也就是不同的数据库会有不同的驱动实现。此时驱动程序这边的程序结构如图24.10所示：

 

图24.10  驱动程序实现结构示意图

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

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

那么此时系统的整体结构如图24.11所示：

 

图24.11  JDBC的结构示意图

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

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

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

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

24.3.4  广义桥接-Java中无处不桥接

       使用Java编写程序，一个很重要的原则就是“面向接口编程”，说得准确点应该是“面向抽象编程”，由于在Java开发中，更多的使用接口而非抽象类，因此通常就说成“面向接口编程”了。

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

 

图24.12  使用接口的程序结构示意图

       可能有些朋友会觉得，听起来怎么像是桥接模式的功能呢？没错，如果把桥接模式的抽象部分先稍稍简化一下，暂时不要RefinedAbstraction部分，那么就跟上面的结构图差不多了。去掉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程序，都可以视为是桥接模式的应用，都是让抽象和实现相分离，从而使它们能独立的变化。不过只要分离的目的达到了，叫不叫桥接模式就无所谓了。

24.3.5  桥接模式的优缺点

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

l          更好的扩展性
    由于桥接模式把抽象和实现部分分离开了，而且分别定义接口，这就使得抽象部分和实现部分可以分别独立的扩展，而不会相互影响，从而大大的提高了系统的可扩展性。

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

l          可减少子类的个数
    根据前面的讲述，对于有两个变化纬度的情况，如果采用继承的实现方式，大约需要两个纬度上的可变化数量的乘积个子类；而采用桥接模式来实现的话，大约需要两个纬度上的可变化数量的和个子类。可以明显地减少子类的个数。

24.3.6  思考桥接模式

1：桥接模式的本质

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

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

       至于其它的好处，比如：可以动态切换实现、可以减少子类个数等。都是把抽象部分和实现部分分离过后，带来的，如果不把抽象部分和实现部分分离开，那就一切免谈了。所以综合来说，桥接模式的本质在于“分离抽象和实现”。

2：对设计原则的体现

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

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

       在使用桥接模式的时候，通常情况下，顶层的Abstraction和Implementor是不变的，而具体的Implementor的实现，是可变的，由于Abstraction是通过接口来操作具体的实现，因此具体的Implementor的实现是可以扩展的，根据需要可以有多个具体的实现。

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

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

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

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

3：何时选用桥接模式

建议在如下情况中，选用桥接模式：

• 如果你不希望在抽象和实现部分采用固定的绑定关系，可以采用桥接模式，来把抽象和实现部分分开，然后在程序运行期间来动态的设置抽象部分需要用到的具体的实现，还可以动态切换具体的实现。
• 如果出现抽象部分和实现部分都应该可以扩展的情况，可以采用桥接模式，让抽象部分和实现部分可以独立的变化，从而可以灵活的进行单独扩展，而不是搅在一起，扩展一边会影响到另一边。
• 如果希望实现部分的修改，不会对客户产生影响，可以采用桥接模式，客户是面向抽象的接口在运行，实现部分的修改，可以独立于抽象部分，也就不会对客户产生影响了，也可以说对客户是透明的。
• 如果采用继承的实现方案，会导致产生很多子类，对于这种情况，可以考虑采用桥接模式，分析功能变化的原因，看看是否能分离成不同的纬度，然后通过桥接模式来分离它们，从而减少子类的数目。

24.3.7  相关模式

l          桥接模式和策略模式
    这两个模式有很大的相似之处。
    如果把桥接模式的抽象部分简化来看，如果暂时不去扩展Abstraction，也就是去掉RefinedAbstraction。桥接模式简化过后的结构图参见图24.13。再看策略模式的结构图参见图17.1。会发现，这个时候它们的结构都类似如图24.18所示：
        
               图24.18  桥接模式和策略模式结构示意图
    通过上面的结构图，可以体会到桥接模式和策略模式是如此相似。可以把策略模式的Context视做是使用接口的对象，而Strategy就是某个接口了，具体的策略实现那就相当于接口的具体实现。这样看来的话，某些情况下，可以使用桥接模式来模拟实现策略模式的功能。
    这两个模式虽然相似，也还是有区别的。最主要的是模式的目的不一样，策略模式的目的是封装一系列的算法，使得这些算法可以相互替换；而桥接模式的目的是分离抽象和实现部分，使得它们可以独立的变化。

l          桥接模式和状态模式
    由于从模式结构上看，状态模式和策略模式是一样的，这两个模式的关系也基本上类似于桥接模式和策略模式的关系。
    只不过状态模式的目的是封装状态对应的行为，并在内部状态改变的时候改变对象的行为。

l          桥接模式和模板方法模式
    这两个模式有相似之处。
    虽然标准的模板方法模式是采用继承来实现的，但是模板方法也可以通过回调接口的方式来实现，如果把接口的实现独立出去，那就类似于模板方法通过接口去调用具体的实现方法了。这样的结构就和简化的桥接模式类似了。
    可以使用桥接模式来模拟实现模板方法模式的功能。如果在实现Abstraction对象的时候，在里面定义方法，方法里面就是某个固定的算法骨架，也就是说这个方法就相当于模板方法。在模板方法模式里，是把不能确定实现的步骤延迟到子类去实现；现在在桥接模式里面，把不能确定实现的步骤委托给具体实现部分去完成，通过回调实现部分的接口，来完成算法骨架中的某些步骤。这样一来，就可以实现使用桥接模式来模拟实现模板方法模式的功能了。
    使用桥接模式来模拟实现模板方法模式的功能，还有个潜在的好处，就是模板方法也可以很方便的扩展和变化了。在标准的模板方法里面，一个问题就是当模板发生变化的时候，所有的子类都要变化，非常不方便。而使用桥接模式来实现类似的功能，就没有这个问题了。
    另外，这里只是说从实现具体的业务功能上，桥接模式可以模拟实现出模板方法模式能实现的功能，并不是说桥接模式和模板方法模式就变成一样的，或者是桥接模式就可以替换掉模板方法模式了。要注意它们本身的功能、目的、本质思想都是不一样的。

l          桥接模式和抽象工厂模式
    这两个模式可以组合使用。
    桥接模式中，抽象部分需要获取相应的实现部分的接口对象，那么谁来创建实现部分的具体实现对象呢？这就是抽象工厂模式派上用场的地方。也就是使用抽象工厂模式来创建和配置一个特定的具体实现的对象。
    事实上，抽象工厂主要是用来创建一系列对象的，如果创建的对象很少，或者是很简单，还可以采用简单工厂，可以达到一样的效果，但是会比抽象工厂来得简单。

l          桥接模式和适配器模式
    这两个模式可以组合使用。
    这两个模式功能是完全不一样的，适配器模式的功能主要是用来帮助无关的类协同工作，重点在解决原本由于接口不兼容而不能一起工作的那些类，使得它们可以一起工作。而桥接模式则重点在分离抽象和实现部分。
    所以在使用上，通常在系统设计完成过后，才会考虑使用适配器模式；而桥接模式，是在系统开始的时候就要考虑使用。
    虽然功能上不一样，这两个模式还是可以组合使用的，比如：已有实现部分的接口，但是有些不太适应现在新的功能对接口的需要，完全抛弃吧，有些功能还用得上，该怎么办呢？那就使用适配器来进行适配，使得旧的接口能够适应新的功能的需要。

 

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

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

研磨设计讨论群【252780326】

原创内容，转载请注明出处【http://sishuok.com/forum/blogPost/list/0/5862.html】

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

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/26715458/viewspace-1070976/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/26715458/viewspace-1070976/