摘要
JDK：1.8.0_202
# 一：场景问题
# 1.1 发送提示消息
考虑一个实际业务功能：某人有新任务，需要发送一条消息提示他。
从业务上看，消息又分成 普通消息、加急消息 和 特急消息 多种，不同的消息类型，业务功能处理是不一样的，比如加急消息是在消息上添加加急，而特急消息除了添加特急外，还会做一条催促的记录，多久不完成会继续催促。
从发送消息的手段上看，又有系统内短消息、手机短消息、邮件等等。
现在要实现这样的发送提示消息的功能，该如何实现呢？
# 1.2 不用模式的解决方案
1. 实现简化版本
先考虑实现一个简单点的版本，比如：消息先只是实现发送普通消息，发送的方式呢，先实现系统内短消息和邮件。其它的功能，等这个版本完成过后，再继续添加，这样先把问题简单化，实现起来会容易一点。
由于发送普通消息会有两种不同的实现方式，为了让外部能统一操作，因此，把消息设计成接口，然后由两个不同的实现类，分别实现系统内短消息方式和邮件发送消息的方式。此时系统结构如图所示：
统一消息接口：(CommonMessageSMS.java 和 CommonMessageEmail.java)
/**
* 以站内短消息的方式发送普通消息
*/
public class CommonMessageSMS implements Message {
public void send(String message, String toUser) {
System.out.println("使用站内短消息的方式，发送消息'" + message + "'给" + toUser);
}
}
2
3
4
5
6
7
8
/**
* 以Email的方式发送普通消息
*/
public class CommonMessageEmail implements Message {
public void send(String message, String toUser) {
System.out.println("使用Email的方式，发送消息'" + message + "'给" + toUser);
}
}
2
3
4
5
6
7
8
2. 实现发送加急消息
接下来，添加发送加急消息的功能，也有两种发送的方式，同样是站内短消息和Email的方式。
**加急消息的实现跟普通消息不同，加急消息会自动在消息上添加加急，然后再发送消息；另外加急消息会提供监控的方法，让客户端可以随时通过这个方法来了解对于加急消息处理的进度，**比如：相应的人员是否接收到这个信息，相应的工作是否已经开展等等。因此加急消息需要扩展出一个新的接口，除了基本的发送消息的功能，还需要添加监控的功能，这个时候，系统的结构如图所示：
加急消息的接口：(UrgencyMessage.java)
/**
* 加急消息的抽象接口
*/
public interface UrgencyMessage extends Message {
/**
* 监控某消息的处理过程
*
* @param messageId 被监控的消息的编号
* @return 包含监控到的数据对象，这里示意一下，所以用了Object
*/
public Object watch(String messageId);
}
2
3
4
5
6
7
8
9
10
11
12
加急消息的实现：(UrgencyMessageSMS.java 和 UrgencyMessageEmail.java)
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;
}
}
2
3
4
5
6
7
8
9
10
11
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;
}
}
2
3
4
5
6
7
8
9
10
11
事实上，在实现加急消息发送的功能上，可能会使用前面发送不同消息的功能，也就是让实现加急消息处理的对象继承普通消息的相应实现，这里为了让结构简单一点，清晰一点，所以没有这样做。
# 1.3 有何问题
1. 继续添加特急消息的处理
特急消息不需要查看处理进程，只要没有完成，就直接催促，也就是说，对于特急消息，在普通消息的处理基础上，需要添加催促的功能。而特急消息、还有催促的发送方式，相应的实现方式还是发送站内短消息和Email两种，此时系统的结构如图所示：
仔细观察上面的系统结构示意图，会发现一个很明显的问题，那就是：通过这种继承的方式来扩展消息处理，会非常不方便。
你看，实现加急消息处理的时候，必须实现站内短消息和Email两种处理方式，因为业务处理可能不同；在实现特急消息处理的时候，又必须实现站内短消息和Email这两种处理方式。
这意味着，以后每次扩展一下消息处理，都必须要实现这两种处理方式，是不是很痛苦，这还不算完，如果要添加新的实现方式呢？继续向下看吧。
2. 继续添加发送手机消息的处理方式
3. 小结出现的问题
采用通过继承来扩展的实现方式，有个明显的缺点：扩展消息的种类不太容易，不同种类的消息具有不同的业务，也就是有不同的实现，在这种情况下，每个种类的消息，需要实现所有不同的消息发送方式。
更可怕的是，如果要新加入一种消息的发送方式，那么会要求所有的消息种类，都要加入这种新的发送方式的实现。
要是考虑业务功能上再扩展一下呢？比如：要求实现群发消息，也就是一次可以发送多条消息，这就意味着很多地方都得修改，太恐怖了。
那么究竟该如何实现才能既实现功能，又能灵活的扩展呢？
# 二：解决方案
用来解决上述问题的一个合理的解决方案，就是使用桥接模式。
桥接模式：将抽象部分与它的实现部分分离，使它们都可以独立地变化。
# 2.1 解决思路
仔细分析上面的示例，根据示例的功能要求，示例的变化具有两个纬度，一个纬度是抽象的消息这边，包括普通消息、加急消息和特急消息，这几个抽象的消息本身就具有一定的关系，加急消息和特急消息会扩展普通消息；另一个纬度在具体的消息发送方式上，包括站内短消息、Email和手机短信息，这几个方式是平等的，可被切换的方式。这两个纬度一共可以组合出9种不同的可能性来，它们的关系如下图所示：
现在出现问题的根本原因，就在于消息的抽象和实现是混杂在一起的，这就导致了，一个纬度的变化，会引起另一个纬度进行相应的变化，从而使得程序扩展起来非常困难。
要想解决这个问题，就必须把这两个纬度分开，也就是将抽象部分和实现部分分开，让它们相互独立，这样就可以实现独立的变化，使扩展变得简单。
# 2.2 模式结构和说明
- Abstraction：抽象部分的接口。通常在这个对象里面，要维护一个实现部分的对象引用，在抽象对象里面的方法，需要调用实现部分的对象来完成。这个对象里面的方法，通常都是跟具体的业务相关的方法。
- RefinedAbstraction：扩展抽象部分的接口，通常在这些对象里面，定义跟实际业务相关的方法，这些方法的实现通常会使用Abstraction中定义的方法，也可能需要调用实现部分的对象来完成。
- Implementor：**定义实现部分的接口，**这个接口不用和Abstraction里面的方法一致，通常是由Implementor接口提供基本的操作，而Abstraction里面定义的是基于这些基本操作的业务方法，也就是说Abstraction定义了基于这些基本操作的较高层次的操作。
- ConcreteImplementor：真正实现Implementor接口的对象。
# 2.3 示例代码
接口定义：(Implementor.java)
/**
* 定义实现部分的接口，可以与抽象部分接口的方法不一样
*/
public interface Implementor {
/**
* 示例方法，实现抽象部分需要的某些具体功能
*/
void operationImpl();
}
2
3
4
5
6
7
8
9
10
11
接口的实现：(ConcreteImplementorA.java 和 ConcreteImplementorB.java)
/**
* 真正的具体实现对象
*/
public class ConcreteImplementorA implements Implementor {
public void operationImpl() {
//真正的实现
}
}
2
3
4
5
6
7
8
/**
* 真正的具体实现对象
*/
public class ConcreteImplementorB implements Implementor {
public void operationImpl() {
//真正的实现
}
}
2
3
4
5
6
7
8
抽象类定义：(Abstraction.java)
/**
* 定义抽象部分的接口
*/
public abstract class Abstraction {
/**
* 持有一个实现部分的对象
*/
protected Implementor impl;
/**
* 构造方法，传入实现部分的对象
*
* @param impl 实现部分的对象
*/
public Abstraction(Implementor impl) {
this.impl = impl;
}
/**
* 示例操作，实现一定的功能，可能需要转调实现部分的具体实现方法
*/
public void operation() {
impl.operationImpl();
}
}2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
抽象类的实现：(RefinedAbstraction.java)
package com.ccjjltx.structural.bridge;
public class RefinedAbstraction extends Abstraction {
public RefinedAbstraction(Implementor impl) {
super(impl);
}
/**
* 示例操作，实现一定的功能
*/
public void otherOperation() {
// 实现一定的功能，可能会使用具体实现部分的实现方法，
// 但是本方法更大的可能是使用Abstraction中定义的方法，
// 通过组合使用Abstraction中定义的方法来完成更多的功能
}
}
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# 2.4 重写案例
要使用桥接模式来重新实现前面的示例，首要任务就是要把抽象部分和实现部分分离出来，分析要实现的功能，抽象部分就是各个消息的类型所对应的功能，而实现部分就是各种发送消息的方式。
其次要按照桥接模式的结构，给抽象部分和实现部分分别定义接口，然后分别实现它们就可以了。
1. 从简单功能开始
从相对简单的功能开始，先实现普通消息和加急消息的功能，发送方式实现站内消息和Email这两种
程序结构如图所示：
消息接口：(MessageImplementor.java)
/**
* 实现发送消息的统一接口
*/
public interface MessageImplementor {
/**
* 发送消息
*
* @param message 要发送的消息内容
* @param toUser 消息发送的目的人员
*/
public void send(String message, String toUser);
}
2
3
4
5
6
7
8
9
10
11
12
13
消息接口的实现：(MessageSMS.java 和 MessageEmail.java)
/**
* 以站内短消息的方式发送消息
*/
public class MessageSMS implements MessageImplementor {
public void send(String message, String toUser) {
System.out.println("使用站内短消息的方式，发送消息'" + message + "'给" + toUser);
}
}
2
3
4
5
6
7
8
9
/**
* 以Email的方式发送消息
*/
public class MessageEmail implements MessageImplementor {
public void send(String message, String toUser) {
System.out.println("使用Email的方式，发送消息'" + message + "'给" + toUser);
}
}
2
3
4
5
6
7
8
抽象类定义：(AbstractMessage.java)
/**
* 抽象的消息对象
*/
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);
}
}
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
抽象类的实现：(CommonMessage.java 和 UrgencyMessage.java)
public class CommonMessage extends AbstractMessage {
public CommonMessage(MessageImplementor impl) {
super(impl);
}
public void sendMessage(String message, String toUser) {
//对于普通消息，什么都不干，直接调父类的方法，把消息发送出去就可以了
super.sendMessage(message, toUser);
}
}
2
3
4
5
6
7
8
9
10
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
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
2. 添加功能
看了上面的实现，发现使用桥接模式来实现也不是很困难啊，关键得看是否能解决前面提出的问题，那就来添加还未实现的功能看看，添加对特急消息的处理，同时添加一个使用手机发送消息的方式。该怎么实现呢？
很简单，只需要在抽象部分再添加一个特急消息的类，扩展抽象消息就可以把特急消息的处理功能加入到系统中了；对于添加手机发送消息的方式也很简单，在实现部分新增加一个实现类，实现用手机发送消息的方式，也就可以了。
这么简单？好像看起来完全没有了前面所提到的问题。的确如此，采用桥接模式来实现过后，抽象部分和实现部分分离开了，可以相互独立的变化，而不会相互影响。因此在抽象部分添加新的消息处理，对发送消息的实现部分是没有影响的；反过来增加发送消息的方式，对消息处理部分也是没有影响的。
手机短消息方式的实现：(MessageMobile.java)
/**
* 以手机短消息的方式发送消息
*/
public class MessageMobile implements MessageImplementor {
public void send(String message, String toUser) {
System.out.println("使用手机短消息的方式，发送消息'" + message + "'给" + toUser);
}
}
2
3
4
5
6
7
8
特急消息处理的实现：(SpecialUrgencyMessage.java)
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
3
4
5
6
7
8
9
10
11
12
13
14
15
3. 测试一下功能
看了上面的实现，可能会感觉得到，使用桥接模式来实现前面的示例过后，添加新的消息处理，或者是新的消息发送方式是如此简单，可是这样实现，好用吗？写个客户端来测试和体会一下，示例代码如下：
Not found: D:\blog\ccj-blog/docs/views/notes/designMode/file/bridge/first/Client.java运行结果：
# 三：模式讲解
# 3.1 认识桥接模式
1. 什么是桥接
在桥接模式里面，不太好理解的就是桥接的概念，什么是桥接？为何需要桥接？如何桥接？把这些问题搞清楚了，也就基本明白桥接的含义了。
一个一个来，先看什么是桥接？**所谓桥接，通俗点说就是在不同的东西之间搭一个桥，让他们能够连接起来，可以相互通讯和使用。**那么在桥接模式中到底是给什么东西来搭桥呢？就是为被分离了的抽象部分和实现部分来搭桥，比如前面示例中抽象的消息和具体消息发送之间搭个桥。
但是这里要注意一个问题：在桥接模式中的桥接是单向的，也就是只能是抽象部分的对象去使用具体实现部分的对象，而不能反过来，也就是个单向桥。
2. 为何需要桥接
为了达到让抽象部分和实现部分都可以独立变化的目的，在桥接模式中，是把抽象部分和实现部分分离开来的，虽然从程序结构上是分开了，但是在抽象部分实现的时候，还是需要使用具体的实现的，这可怎么办呢？抽象部分如何才能调用到具体实现部分的功能呢？很简单，搭个桥不就可以了，搭个桥，让抽象部分通过这个桥就可以调用到实现部分的功能了，因此需要桥接。
3. 如何桥接
这个理解上也很简单，只要让抽象部分拥有实现部分的接口对象，这就桥接上了，在抽象部分就可以通过这个接口来调用具体实现部分的功能。也就是说，桥接在程序上就体现成了在抽象部分拥有实现部分的接口对象，维护桥接就是维护这个关系。
4. 独立变化
桥接模式的意图：使得抽象和实现可以独立变化，都可以分别扩充。也就是说抽象部分和实现部分是一种非常松散的关系，从某个角度来讲，抽象部分和实现部分是可以完全分开的，独立的，抽象部分不过是一个使用实现部分对外接口的程序罢了。
如果这么看桥接模式的话，就类似于策略模式了，抽象部分需要根据某个策略，来选择真实的实现，也就是说桥接模式的抽象部分相当于策略模式的上下文。更原始的就直接类似于面向接口编程，通过接口分离的两个部分而已。但是别忘了，桥接模式的抽象部分，是可以继续扩展和变化的，而策略模式只有上下文，是不存在所谓抽象部分的。
那抽象和实现为何还要组合在一起呢？原因是在抽象部分和实现部分还是存在内部联系的，抽象部分的实现通常是需要调用实现部分的功能来实现的。
5. 动态变换功能
由于桥接模式中的抽象部分和实现部分是完全分离的，因此可以在运行时动态组合具体的真实实现，从而达到动态变换功能的目的。
从另外一个角度看，抽象部分和实现部分没有固定的绑定关系了，因此同一个真实实现可以被不同的抽象对象使用，反过来，同一个抽象也可以有多个不同的实现。就像前面示例的那样，比如：站内短消息的实现功能，可以被普通消息、加急消息或是特急消息等不同的消息对象使用；反过来，某个消息具体的发送方式，可以是站内短消息，或者是Email，也可以是手机短消息等具体的发送方式。
6. 桥接模式和继承
继承是扩展对象功能的一种常见手段，通常情况下，继承扩展的功能变化纬度都是一纬的，也就是变化的因素只有一类。
对于出现变化因素有两类的，也就是有两个变化纬度的情况，继承实现就会比较痛苦。比如上面的示例，就有两个变化纬度，一个是消息的类别，不同的消息类别处理不同；另外一个是消息的发送方式。
从理论上来说，如果用继承的方式来实现这种有两个变化纬度的情况，最后实际的实现类应该是两个纬度上可变数量的乘积那么多个。比如上面的示例，在消息类别的纬度上，目前的可变数量是3个，普通消息、加急消息和特急消息；在消息发送方式的纬度上，目前的可变数量也是3个，站内短消息、Email和手机短消息。这种情况下，如果要实现全的话，那么需要的实现类应该是：3 X 3 = 9个。
如果要在任何一个纬度上进行扩展，都需要实现另外一个纬度上的可变数量那么多个实现类，这也是为何会感到扩展起来很困难。而且随着程序规模的加大，会越来越难以扩展和维护。
而桥接模式就是用来解决这种有两个变化纬度的情况下，如何灵活的扩展功能的一个很好的方案。其实，桥接模式主要是把继承改成了使用对象组合，从而把两个纬度分开，让每一个纬度单独去变化，最后通过对象组合的方式，把两个纬度组合起来，每一种组合的方式就相当于原来继承中的一种实现，这样就有效的减少了实际实现的类的个数。
从理论上来说，如果用桥接模式的方式来实现这种有两个变化纬度的情况，最后实际的实现类应该是两个纬度上可变数量的和那么多个。同样是上面那个示例，使用桥接模式来实现，实现全的话，最后需要的实现类的数目应该是：3 + 3 = 6个。
这也从侧面体现了，使用对象组合的方式比继承要来得更灵活。
# 3.2 谁来桥接
所谓谁来桥接，就是谁来负责创建抽象部分和实现部分的关系，说得更直白点，就是谁来负责创建Implementor的对象，并把它设置到抽象部分的对象里面去，这点对于使用桥接模式来说，是十分重要的一点。
大致有如下几种实现方式：
由客户端负责创建Implementor的对象，并在创建抽象部分的对象的时候，把它设置到抽象部分的对象里面去，前面的示例采用的就是这个方式
可以在抽象部分的对象构建的时候，由抽象部分的对象自己来创建相应的Implementor的对象，当然可以给它传递一些参数，它可以根据参数来选择并创建具体的Implementor的对象
可以在Abstraction中选择并创建一个缺省的Implementor的对象，然后子类可以根据需要改变这个实现
也可以使用抽象工厂或者简单工厂来选择并创建具体的Implementor的对象，抽象部分的类可以通过调用工厂的方法来获取Implementor的对象
如果使用IoC/DI容器的话，还可以通过IoC/DI容器来创建具体的Implementor的对象，并注入回到Abstraction中
# 3.3 优缺点
1. 分离抽象和实现部分
桥接模式分离了抽象和实现部分，从而极大地提高了系统的灵活性。**让抽象部分和实现部分独立开来，分别定义接口，这有助于对系统进行分层，从而产生更好的结构化的系统。**对于系统的高层部分，只需要知道抽象部分和实现部分的接口就可以了。
2. 更好的扩展性
由于桥接模式把抽象和实现部分分离开了，而且分别定义接口，这就使得抽象部分和实现部分可以分别独立的扩展，而不会相互影响，从而大大的提高了系统的可扩展性。可动态切换实现。
由于桥接模式把抽象和实现部分分离开了，那么在实现桥接的时候，就可以实现动态的选择和使用具体的实现，也就是说一个实现不再是固定的绑定在一个抽象接口上了，可以实现运行期间动态的切换实现。
3. 可减少子类的个数
根据前面的讲述，对于有两个变化纬度的情况，如果采用继承的实现方式，大约需要两个纬度上的可变化数量的乘积个子类；而采用桥接模式来实现的话，大约需要两个纬度上的可变化数量的和个子类。可以明显地减少子类的个数
# 3.4 思考桥接模式
1. 桥接模式的本质
桥接模式的本质：分离抽象和实现。
桥接模式最重要的工作就是分离抽象部分和实现部分，这是解决问题的关键。只有把抽象和实现分离开了，才能够让它们可以独立的变化；只有抽象和实现可以独立的变化，系统才会有更好的可扩展性、可维护性。
至于其它的好处，比如：可以动态切换实现、可以减少子类个数等。都是把抽象部分和实现部分分离过后，带来的，如果不把抽象部分和实现部分分离开，那就一切免谈了。所以综合来说，桥接模式的本质在于“分离抽象和实现”。
2. 对设计原则的体现
（1）桥接模式很好的实现了开闭原则
通常应用桥接模式的地方，抽象部分和实现部分都是可变化的，也就是应用会有两个变化纬度，桥接模式就是找到这两个变化，并分别封装起来，从而合理的实现OCP。
在使用桥接模式的时候，通常情况下，顶层的Abstraction和Implementor是不变的，而具体的Implementor的实现，是可变的，由于Abstraction是通过接口来操作具体的实现，因此具体的Implementor的实现是可以扩展的，根据需要可以有多个具体的实现。
同样的，RefinedAbstraction也是可变的，它继承并扩展Abstraction，通常在RefinedAbstraction的实现里面，会调用Abstraction中的方法，通过组合使用来完成更多的功能，这些功能常常是与具体业务有关系的功能。
（2）桥接模式还很好的体现了：多用对象组合，少用对象继承
在前面的示例中，如果使用对象继承来扩展功能，不但让对象之间有很强的耦合性，而且会需要很多的子类才能完成相应的功能，前面已经讲述过了，需要两个纬度上的可变化数量的乘积个子类。
而采用对象的组合，松散了对象之间的耦合性，不但使每个对象变得简单和可维护，还大大减少了子类的个数，根据前面的讲述，大约需要两个纬度上的可变化数量的和这么多个子类。
3. 何时选用桥接模式
建议在如下情况中，选用桥接模式：
如果你不希望在抽象和实现部分采用固定的绑定关系，可以采用桥接模式，来把抽象和实现部分分开，然后在程序运行期间来动态的设置抽象部分需要用到的具体的实现，还可以动态切换具体的实现。
如果出现抽象部分和实现部分都应该可以扩展的情况，可以采用桥接模式，让抽象部分和实现部分可以独立的变化，从而可以灵活的进行单独扩展，而不是搅在一起，扩展一边会影响到另一边。
如果希望实现部分的修改，不会对客户产生影响，可以采用桥接模式，客户是面向抽象的接口在运行，实现部分的修改，可以独立于抽象部分，也就不会对客户产生影响了，也可以说对客户是透明的。
如果采用继承的实现方案，会导致产生很多子类，对于这种情况，可以考虑采用桥接模式，分析功能变化的原因，看看是否能分离成不同的纬度，然后通过桥接模式来分离它们，从而减少子类的数目。
# 3.5 相关模式
1. 桥接模式和策略模式
这两个模式有很大的相似之处。
如果把桥接模式的抽象部分简化来看，如果暂时不去扩展Abstraction，也就是去掉RefinedAbstraction。会发现，这个时候它们的结构都类似。可以把策略模式的Context视做是使用接口的对象，而Strategy就是某个接口了，具体的策略实现那就相当于接口的具体实现。这样看来的话，某些情况下，可以使用桥接模式来模拟实现策略模式的功能。
这两个模式虽然相似，也还是有区别的。最主要的是模式的目的不一样，策略模式的目的是封装一系列的算法，使得这些算法可以相互替换；而桥接模式的目的是分离抽象和实现部分，使得它们可以独立的变化。
2. 桥接模式和状态模式
由于从模式结构上看，状态模式和策略模式是一样的，这两个模式的关系也基本上类似于桥接模式和策略模式的关系。
只不过状态模式的目的是封装状态对应的行为，并在内部状态改变的时候改变对象的行为。
3. 桥接模式和模板方法模式
这两个模式有相似之处。
虽然标准的模板方法模式是采用继承来实现的，但是模板方法也可以通过回调接口的方式来实现，如果把接口的实现独立出去，那就类似于模板方法通过接口去调用具体的实现方法了。这样的结构就和简化的桥接模式类似了。
可以使用桥接模式来模拟实现模板方法模式的功能。如果在实现Abstraction对象的时候，在里面定义方法，方法里面就是某个固定的算法骨架，也就是说这个方法就相当于模板方法。在模板方法模式里，是把不能确定实现的步骤延迟到子类去实现；现在在桥接模式里面，把不能确定实现的步骤委托给具体实现部分去完成，通过回调实现部分的接口，来完成算法骨架中的某些步骤。这样一来，就可以实现使用桥接模式来模拟实现模板方法模式的功能了。
使用桥接模式来模拟实现模板方法模式的功能，还有个潜在的好处，就是模板方法也可以很方便的扩展和变化了。**在标准的模板方法里面，一个问题就是当模板发生变化的时候，所有的子类都要变化，非常不方便。**而使用桥接模式来实现类似的功能，就没有这个问题了。
另外，这里只是说从实现具体的业务功能上，桥接模式可以模拟实现出模板方法模式能实现的功能，并不是说桥接模式和模板方法模式就变成一样的，或者是桥接模式就可以替换掉模板方法模式了。要注意它们本身的功能、目的、本质思想都是不一样的。
4. 桥接模式和抽象工厂模式
这两个模式可以组合使用。
桥接模式中，抽象部分需要获取相应的实现部分的接口对象，那么谁来创建实现部分的具体实现对象呢？这就是抽象工厂模式派上用场的地方。也就是使用抽象工厂模式来创建和配置一个特定的具体实现的对象。
事实上，抽象工厂主要是用来创建一系列对象的，如果创建的对象很少，或者是很简单，还可以采用简单工厂，可以达到一样的效果，但是会比抽象工厂来得简单。
5. 桥接模式和适配器模式
这两个模式可以组合使用。
这两个模式功能是完全不一样的，适配器模式的功能主要是用来帮助无关的类协同工作，重点在解决原本由于接口不兼容而不能一起工作的那些类，使得它们可以一起工作。而桥接模式则重点在分离抽象和实现部分。
所以在使用上，通常在系统设计完成过后，才会考虑使用适配器模式；而桥接模式，是在系统开始的时候就要考虑使用。
虽然功能上不一样，这两个模式还是可以组合使用的，比如：已有实现部分的接口，但是有些不太适应现在新的功能对接口的需要，完全抛弃吧，有些功能还用得上，该怎么办呢？那就使用适配器来进行适配，使得旧的接口能够适应新的功能的需要。
# 四：JDK
- AWT (It provides an abstraction layer which maps onto the native OS the windowing support.)
- JDBC