原博文:https://blog.csdn.net/KongZhongNiao/article/details/80704196
学习桥接模式
一:初识桥接模式
包括:定义、结构、参考实现
二:体会桥接模式
包括:场景问题、不用模式的解决方案、使用模式的解决方案
三:理解桥接模式
包括:认识桥接模式、谁来桥接、典型例子-JDBC 、
广义桥接-Java中无处不桥接 、桥接模式的优缺点
四:思考桥接模式
包括:桥接模式的本质、对设计原则的体现、何时选用
初识桥接模式
定义
将抽象部分与它的实现部分分离,使它们都可以独立地变化。
结构和说明
Abstraction:
抽象部分的接口。通常在这个对象里面,要维护一个实现部分的对象引
用,在抽象对象里面的方法,需要调用实现部分的对象来完成。这个对象里面的
方法,通常都是跟具体的业务相关的方法。
RefinedAbstraction:
扩展抽象部分的接口,通常在这些对象里面,定义跟实际业务相关的方
法,这些方法的实现通常会使用Abstraction中定义的方法,也可能需要调用实
现部分的对象来完成。
Implementor:
定义实现部分的接口,这个接口不用和Abstraction里面的方法一致,通常
是由Implementor接口提供基本的操作,而Abstraction里面定义的是基于这些基
本操作的业务方法,也就是说Abstraction定义了基于这些基本操作的较高层次
的操作。
ConcreteImplementor:
真正实现Implementor接口的对象。
示例代码
定义抽象部分的接口
package cn.javass.dp.bridge.example5;
/**
* 定义抽象部分的接口
*/
public abstract class Abstraction {
/**
* 持有一个实现部分的对象
*/
protected Implementor impl;
/**
* 构造方法,传入实现部分的对象
* @param impl 实现部分的对象
*/
public Abstraction(Implementor impl){
this.impl = impl;
}
/**
* 示例操作,实现一定的功能,可能需要转调实现部分的具体实现方法
*/
public void operation() {
impl.operationImpl();
}
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
扩充由Abstraction定义的接口功能
package cn.javass.dp.bridge.example5;
/**
* 扩充由Abstraction定义的接口功能
*/
public class RefinedAbstraction extends Abstraction {
public RefinedAbstraction(Implementor impl) {
super(impl);
}
/**
* 示例操作,实现一定的功能,可能会使用具体实现部分的实现方法,
* 但是本方法更大的可能是使用Abstraction中定义的方法,
* 通过组合使用Abstraction中定义的方法来完成更多的功能
*/
public void otherOperation(){
//
}
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
定义实现部分的接口,可以与抽象部分接口的方法不一样
package cn.javass.dp.bridge.example5;
/**
* 定义实现部分的接口,可以与抽象部分接口的方法不一样
*/
public interface Implementor {
/**
* 示例方法,实现抽象部分需要的某些具体功能
*/
public void operationImpl();
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
真正的具体实现对象
package cn.javass.dp.bridge.example5;
/**
* 真正的具体实现对象
*/
public class ConcreteImplementorA implements Implementor {
public void operationImpl() {
//真正的实现
}
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
真正的具体实现对象
package cn.javass.dp.bridge.example5;
/**
* 真正的具体实现对象
*/
public class ConcreteImplementorB implements Implementor {
public void operationImpl() {
//真正的实现
}
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
体会桥接模式
发送提示消息
考虑这样一个实际的业务功能:发送提示消息。基本上所有带业务流程处
理的系统都会有这样的功能,比如某人有新的工作了,需要发送一条消息提示
他。
从业务上看,消息又分成普通消息、加急消息和特急消息多种,不同的消
息类型,业务功能处理是不一样的,比如加急消息是在消息上添加加急,而特急
消息除了添加特急外,还会做一条催促的记录,多久不完成会继续催促。从发送
消息的手段上看,又有系统内短消息、手机短消息、邮件等等。
现在要实现这样的发送提示消息的功能,该如何实现呢?
不用模式的解决方案
1:实现简化版本
先考虑实现一个简单点的版本,比如:消息先只是实现发送普通消息,发
送的方式呢,先实现系统内短消息和邮件。其它的功能,等这个版本完成过后,
再继续添加,这样先把问题简单化,实现起来会容易一点。
(1)由于发送普通消息会有两种不同的实现方式,为了让外部能统一操作,因此,
把消息设计成接口,然后由两个不同的实现类,分别实现系统内短消息方式和邮
件发送消息的方式。此时系统结构如图
示例代码
消息的统一接口
package cn.javass.dp.bridge.example1;
/**
* 消息的统一接口
*/
public interface Message {
/**
* 发送消息
* @param message 要发送的消息内容
* @param toUser 把消息发送的目的人员
*/
public void send(String message,String toUser);
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
以Email的方式发送普通消息
package cn.javass.dp.bridge.example1;
/**
* 以Email的方式发送普通消息
*/
public class CommonMessageEmail implements Message{
public void send(String message, String toUser) {
System.out.println("使用Email的方式,发送消息'"+message+"'给"+toUser);
}
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
以站内短消息的方式发送普通消息
package cn.javass.dp.bridge.example1;
/**
* 以站内短消息的方式发送普通消息
*/
public class CommonMessageSMS implements Message{
public void send(String message, String toUser) {
System.out.println("使用站内短消息的方式,发送消息'"+message+"'给"+toUser);
}
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
客户端
package cn.javass.dp.bridge.example1;
public class Client {
public static void main(String[] args) {
Message m = new CommonMessageSMS();
m.send("aa", "au");
m = new CommonMessageEmail();
m.send("aa", "au");
}
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
2:实现发送加急消息
添加发送加急消息的功能,同样是站内短消息和Email的方式。
加急消息的实现跟普通消息不同,加急消息会自动在消息上添加加急,然后再发送
消息;另外加急消息会提供监控的方法,让客户端可以随时通过这个方法来了解对于加急
消息处理的进度等。因此加急消息需要扩展出一个新的接口,除了基本的发送消息的功
能,还需要添加监控的功能,这个时候,系统的结构如图 :
客户端
加急消息的抽象接口
package cn.javass.dp.bridge.example2;
/**
* 加急消息的抽象接口
*/
public interface UrgencyMessage extends Message{
/**
* 监控某消息的处理过程
* @param messageId 被监控的消息的编号
* @return 包含监控到的数据对象,这里示意一下,所以用了Object
*/
public Object watch(String messageId);
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
加急 Email
package cn.javass.dp.bridge.example2;
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;
}
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
加急 SMS
package cn.javass.dp.bridge.example2;
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;
}
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
客户端
package cn.javass.dp.bridge.example2;
public class Client {
public static void main(String[] args) {
Message m = new UrgencyMessageEmail();
m.send("aa", "au");
m = new CommonMessageEmail();
m.send("aa", "au");
}
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
有何问题
上面这样实现,好像也能满足基本的功能要求,可是这么实现好不好呢?
有没有什么问题呢?
咱们继续向下来添加功能实现,为了简洁,就不再去进行代码示意了,通
过实现的结构示意图就可以看出实现上的问题。
1:继续添加特急消息的处理
特急消息不需要查看处理进程,只要没有完成,就直接催促,也就是说,
对于特急消息,在普通消息的处理基础上,需要添加催促的功能。而特急消息、
还有催促的发送方式,相应的实现方式还是发送站内短消息和Email两种,此时
系统的结构如图:
示例
特急消息的抽象接口
package cn.javass.dp.bridge.example4;
/**
* 特急消息的抽象接口
*/
public interface SpecialUrgencyMessage extends Message{
public void hurry(String messageId);
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
特急Email
package cn.javass.dp.bridge.example4;
public class SpecialUrgencyMessageEmail implements SpecialUrgencyMessage{
public void hurry(String messageId) {
// TODO Auto-generated method stub
}
public void send(String message, String toUser) {
// TODO Auto-generated method stub
}
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
特急EmailSMS
package cn.javass.dp.bridge.example4;
public class SpecialUrgencyMessageSMS implements SpecialUrgencyMessage{
public void hurry(String messageId) {
// TODO Auto-generated method stub
}
public void send(String message, String toUser) {
// TODO Auto-generated method stub
}
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
仔细观察上面的系统结构示意图,会发现一个很明显的问题,那就是:通
过这种继承的方式来扩展消息处理,会非常不方便。
你看,实现加急消息处理的时候,必须实现站内短消息和Email两种处理方
式,因为业务处理可能不同;在实现特急消息处理的时候,又必须实现站内短消
息和Email这两种处理方式。
这意味着,以后每次扩展一下消息处理,都必须要实现这两种处理方式,
是不是很痛苦,这还不算完,如果要添加新的实现方式呢?继续向下看吧。
2:继续添加发送手机消息的处理方式
如果看到上面的实现,你还感觉问题不是很大的话,继续完成功能,添加
发送手机消息的处理方式。
仔细观察现在的实现,如果要添加一种新的发送消息的方式,是需要在每
一种抽象的具体实现里面,都要添加发送手机消息的处理的。也就是说:发送普
通消息、加急消息和特急消息的处理,都可以通过手机来发送。这就意味着,需
要添加三个实现。此时系统结构如图:
示例
手机发送普通消息
package cn.javass.dp.bridge.example4;
public class CommonMessageMobile implements Message{
public void send(String message, String toUser) {
}
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
手机发送加急消息
package cn.javass.dp.bridge.example4;
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;
}
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
手机 发送 特急消息
package cn.javass.dp.bridge.example4;
public class SpecialUrgencyMessageMobile implements SpecialUrgencyMessage{
public void hurry(String messageId) {
// TODO Auto-generated method stub
}
public void send(String message, String toUser) {
// TODO Auto-generated method stub
}
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
3:小结一下出现的问题
采用通过继承来扩展的实现方式,有个明显的缺点:扩展消息的种类不太
容易,不同种类的消息具有不同的业务,也就是有不同的实现,在这种情况下,
每个种类的消息,需要实现所有不同的消息发送方式。
更可怕的是,如果要新加入一种消息的发送方式,那么会要求所有的消息
种类,都要加入这种新的发送方式的实现。
要是考虑业务功能上再扩展一下呢?比如:要求实现群发消息,也就是一
次可以发送多条消息,这就意味着很多地方都得修改,太恐怖了。
那么究竟该如何实现才能既实现功能,又能灵活的扩展呢?
使用模式来解决的思路
仔细分析上面的示例,根据示例的功能要求,示例的变化具有两个纬度,
一个纬度是抽象的消息这边,包括普通消息、加急消息和特急消息,这几个抽象
的消息本身就具有一定的关系,加急消息和特急消息会扩展普通消息;另一个纬
度在具体的消息发送方式上,包括站内短消息、Email和手机短信息,这几个方
式是平等的,可被切换的方式。这两个纬度一共可以组合出9种不同的可能性
来,它们的关系如下图
现在出现问题的根本原因,就在于消息的抽象和实现是混杂在一起的,这
就导致了,一个纬度的变化,会引起另一个纬度进行相应的变化,从而使得程序
扩展起来非常困难。
要想解决这个问题,就必须把这两个纬度分开,也就是将抽象部分和实现
部分分开,让它们相互独立,这样就可以实现独立的变化,使扩展变得简单。
桥接模式通过引入实现的接口,把实现部分从系统中分离出去;那么,抽
象这边如何使用具体的实现呢?肯定是面向实现的接口来编程了,为了让抽象这
边能够很方便的与实现结合起来,把顶层的抽象接口改成抽象类,在里面持有一
个具体的实现部分的实例。
这样一来,对于需要发送消息的客户端而言,就只需要创建相应的消息对
象,然后调用这个消息对象的方法就可以了,这个消息对象会调用持有的真正的
消息发送方式来把消息发送出去。也就是说客户端只是想要发送消息而已,并不
想关心具体如何发送。
使用模式来解决
首要任务是把抽象部分和实现部分分离出来,分析要实现的功能,抽象部分就是各
个消息的类型所对应的功能,而实现部分就是各种发送消息的方式。
其次要给抽象部分和实现部分分别定义接口,然后分别实现它们。
1:从简单功能开始
从相对简单的功能开始,先实现普通消息和加急消息的功能,发送方式先实现站内
短消息和Email这两种。使用桥接模式来实现这些功能的程序结构如图
示例
抽象的消息对象
package cn.javass.dp.bridge.example6;
/**
* 抽象的消息对象
*/
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);
}
}
- 1
- 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
普通消息
package cn.javass.dp.bridge.example6;
/**
* 普通消息
*/
public class CommonMessage extends AbstractMessage{
public CommonMessage(MessageImplementor impl) {
super(impl);
}
public void sendMessage(String message, String toUser) {
//对于普通消息,什么都不干,直接调用父类的方法,把消息发送出去就可以了
super.sendMessage(message, toUser);
}
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
加急消息
package cn.javass.dp.bridge.example6;
/**
* 加急消息
*/
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;
}
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
特急消息
package cn.javass.dp.bridge.example6;
/**
* 特急消息
*/
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);
//还需要增加一条待催促的信息
}
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
实现发送消息的统一接口
package cn.javass.dp.bridge.example6;
/**
* 实现发送消息的统一接口
*/
public interface MessageImplementor {
/**
* 发送消息
* @param message 要发送的消息内容
* @param toUser 把消息发送的目的人员
*/
public void send(String message,String toUser);
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
以Email的方式发送消息
package cn.javass.dp.bridge.example6;
/**
* 以Email的方式发送消息
*/
public class MessageEmail implements MessageImplementor{
public void send(String message, String toUser) {
System.out.println("使用Email的方式,发送消息'"+message+"'给"+toUser);
}
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
以手机短消息的方式发送消息
package cn.javass.dp.bridge.example6;
/**
* 以手机短消息的方式发送消息
*/
public class MessageMobile implements MessageImplementor{
public void send(String message, String toUser) {
System.out.println("使用手机短消息的方式,发送消息'"+message+"'给"+toUser);
}
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
以站内短消息的方式发送消息
package cn.javass.dp.bridge.example6;
/**
* 以站内短消息的方式发送消息
*/
public class MessageSMS implements MessageImplementor{
public void send(String message, String toUser) {
System.out.println("使用站内短消息的方式,发送消息'"+message+"'给"+toUser);
}
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
客户端
package cn.javass.dp.bridge.example6;
public class Client {
public static void main(String[] args) {
//创建具体的实现对象
MessageImplementor impl = new MessageEmail();
//创建一个普通消息对象
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
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
2:添加功能
看了上面的实现,发现使用桥接模式来实现也不是很困难啊,关键得看是
否能解决前面提出的问题,那就来添加还未实现的功能看看,添加对特急消息的
处理,同时添加一个使用手机发送消息的方式。该怎么实现呢?
很简单,只需要在抽象部分再添加一个特急消息的类,扩展抽象消息就可
以把特急消息的处理功能加入到系统中了;对于添加手机发送消息的方式也很简
单,在实现部分新增加一个实现类,实现用手机发送消息的方式,也就可以了。
这么简单?好像看起来完全没有了前面所提到的问题。的确如此,采用桥
接模式来实现过后,抽象部分和实现部分分离开了,可以相互独立的变化,而不
会相互影响。因此在抽象部分添加新的消息处理,对发送消息的实现部分是没有
影响的;反过来增加发送消息的方式,对消息处理部分也是没有影响的。
理解桥接模式
认识桥接模式
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:桥接模式的调用顺序示意图
谁来桥接
所谓谁来桥接,就是谁来负责创建抽象部分和实现部分的关系,说得更直白点,就
是谁来负责创建Implementor的对象,并把它设置到抽象部分的对象里面去,这点对于使用
桥接模式来说,是十分重要的一点。
大致有如下几种实现方式:
1:由客户端负责创建Implementor的对象,并在创建抽象部分的对象的时候,把它设置到抽象
部分的对象里面去,前面的示例采用的就是这个方式2:可以在抽象部分的对象构建的时候,由抽象部分的对象自己来创建相应的Implementor的对
象,当然可以给它传递一些参数,它可以根据参数来选择并创建具体的Implementor的对象3:可以在Abstraction中选择并创建一个缺省的Implementor的对象,然后子类可以根据需要
改变这个实现4:也可以使用抽象工厂或者简单工厂来选择并创建具体的Implementor的对象,抽象部分的类
可以通过调用工厂的方法来获取Implementor的对象- 5:如果使用IoC/DI容器的话,还可以通过IoC/DI容器来创建具体的Implementor的对象,并注
入回到Abstraction中
下面分别给出后面几种实现方式的示例:
1:由抽象部分的对象自己来创建相应的Implementor的对象
分成两种情况,一种是需要外部传入参数,一种是不需要外部传入参数。
需要外部传入参数
package cn.javass.dp.bridge.example7;
/**
* 抽象的消息对象
*/
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);
}
}
- 1
- 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
- 30
- 31
- 32
- 33
- 34
不需要外部传入参数
package cn.javass.dp.bridge.example7;
/**
* 抽象的消息对象
*/
public abstract class AbstractMessage2 {
/**
* 根据消息的长度来选择合适的实现
* @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;
}
/**
* 构造方法
*/
public AbstractMessage2(){
//现在什么都不做了
}
/**
* 发送消息,转调实现部分的方法
* @param message 要发送的消息内容
* @param toUser 把消息发送的目的人员
*/
public void sendMessage(String message,String toUser){
this.getImpl(message).send(message, toUser);
}
}
- 1
- 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
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
2:在Abstraction中创建缺省的Implementor对象
对于这种方式,实现比较简单,直接在Abstraction的构造方法中,创建一个缺省的
Implementor对象,然后子类根据需要,看是直接使用还是覆盖掉。
创建一个默认的实现
package cn.javass.dp.bridge.example7;
/**
* 抽象的消息对象
*/
public abstract class AbstractMessage3 {
/**
* 持有一个实现部分的对象
*/
protected MessageImplementor impl;
/**
* 构造方法
*/
public AbstractMessage3(){
//创建一个默认的实现
this.impl = new MessageSMS();
}
/**
* 发送消息,转调实现部分的方法
* @param message 要发送的消息内容
* @param toUser 把消息发送的目的人员
*/
public void sendMessage(String message,String toUser){
this.impl.send(message, toUser);
}
}
- 1
- 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
3:使用抽象工厂或者是简单工厂
对于这种方式,根据具体需要来选择,如果是想要创建一系列实现对象,那就使用
抽象工厂,如果是创建单个的实现对象,那就使用简单工厂。
这种方法的优点是Abstraction类不用和任何一个Implementor类直接耦合。
4:使用IoC/DI的方式
对于这种方式,Abstraction的实现就更简单了,只需要实现注入Implementor对象
的方法就可以了,其它的Abstraction就不管了。
IoC/DI容器会负责创建Implementor对象,并设置回到Abstraction对象中,使用
IoC/DI的方式,并不会改变Abstraction和Implementor的关系,Abstraction同样需要持有
相应的Implementor对象,同样会把功能委托给Implementor对象去实现。
典型例子-JDBC
在Java应用中,对于桥接模式有一个非常典型的例子,就是:应用程序使
用JDBC驱动程序进行开发的方式。所谓驱动程序,指的是按照预先约定好的接口
来操作计算机系统或者是外围设备的程序。
示例
package cn.javass.dp.bridge.example8;
import java.sql.*;
import java.sql.DriverManager;
public class JDBCTest {
public static void main(String[] args) throws Exception {
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();
}
}
- 1
- 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
- 30
- 31
- 32
- 33
我们写的应用程序,是面向JDBC的API在开发,这些接口就相当于桥接模式
中的抽象部分的接口。那么怎样得到这些API的呢?是通过DriverManager来得到
的。此时的系统结构如图
那么这些JDBC的API,谁去实现呢?光有接口,没有实现也不行啊。
该驱动程序登场了,JDBC的驱动程序实现了JDBC的API,驱动程序就相当于
桥接模式中的具体实现部分。而且不同的数据库,由于数据库实现不一样,可执
行的Sql也不完全一样,因此对于JDBC驱动的实现也是不一样的,也就是不同的
数据库会有不同的驱动实现。此时驱动程序这边的程序结构如图
有了抽象部分——JDBC的API,有了具体实现部分——驱动程序,那么它们
如何连接起来呢?就是如何桥接呢?
就是前面提到的DriverManager来把它们桥接起来,从某个侧面来看,
DriverManager在这里起到了类似于简单工厂的功能,基于JDBC的应用程序需要
使用JDBC的API,如何得到呢?就通过DriverManager来获取相应的对象。
那么此时系统的整体结构如图
通过上图可以看出,基于JDBC的应用程序,使用JDBC的API,相当于是对数
据库操作的抽象的扩展,算作桥接模式的抽象部分;而具体的接口实现是由驱动
来完成的,驱动这边自然就相当于桥接模式的实现部分了。而桥接的方式,不再
是让抽象部分持有实现部分,而是采用了类似于工厂的做法,通过
DriverManager来把抽象部分和实现部分对接起来,从而实现抽象部分和实现部
分解耦。
JDBC的这种架构,把抽象和具体分离开来,从而使得抽象和具体部分都可
以独立扩展。对于应用程序而言,只要选用不同的驱动,就可以让程序操作不同
的数据库,而无需更改应用程序,从而实现在不同的数据库上移植;对于驱动程
序而言,为数据库实现不同的驱动程序,并不会影响应用程序。而且,JDBC的这
种架构,还合理的划分了应用程序开发人员和驱动程序开发人员的边界。
广义桥接-Java中无处不桥接
使用Java编写程序,一个很重要的原则就是“面向接口编程”,说得准确
点应该是“面向抽象编程”,由于在Java开发中,更多的使用接口而非抽象类,
因此通常就说成“面向接口编程”了。
接口把具体的实现和使用接口的客户程序分离开来,从而使得具体的实现
和使用接口的客户程序可以分别扩展,而不会相互影响。结构如图
可能有些朋友会觉得,听起来怎么像是桥接模式的功能呢?没错,如果把
桥接模式的抽象部分先稍稍简化一下,暂时不要RefinedAbstraction部分,那么
就跟上面的结构图差不多了。去掉RefinedAbstraction后的简化的桥接模式结构
示意图如图
是不是差不多呢?有朋友可能会觉得还是有很大差异,差异主要在:前面接口
的客户程序是直接使用接口对象,不像桥接模式的抽象部分那样,是持有具体实现部
分的接口,这就导致画出来的结构图,一个是依赖,一个是聚合关联。
请思考它们的本质功能,桥接模式中的抽象部分持有具体实现部分的接口,最
终目的是什么,还不是需要通过调用具体实现部分的接口中的方法,来完成一定的功
能,这跟直接使用接口没有什么不同,只是表现形式有点不一样。再说,前面那个使
用接口的客户程序也可以持有相应的接口对象,这样从形式上就一样了。
也就是说,从某个角度来讲,桥接模式不过就是对“面向抽象编程”这个设计
原则的扩展。正是通过具体实现的接口,把抽象部分和具体的实现分离开来,抽象部
分相当于是使用实现部分接口的客户程序,这样抽象部分和实现部分就松散耦合了,
从而可以实现相互独立的变化。
这样一来,几乎可以把所有面向抽象编写的程序,都视作是桥接模式的体现,
至少算是简化的桥接模式,就算是广义的桥接吧。而Java编程很强调“面向抽象编
程”,因此,广义的桥接,在Java中可以说是无处不在。
再举个大家最熟悉的例子来示例一下。在Java应用开发中,分层实现算是最基
本的设计方式了吧,就拿大家最熟的三层架构来说,表现层、逻辑层和数据层,或许
有些朋友对它们称呼的名称不同,但都是同一回事情。
三层的基本关系是表现层调用逻辑层,逻辑层调用数据层,通过什么来进行调
用呢?当然是接口了,它们的基本结构如图
通过接口来进行调用,使得表现层和逻辑层分离开来,也就是说表现层的变
化,不会影响到逻辑层,同理逻辑层的变化不会影响到表现层。这也是同一套逻辑层
和数据层,就能够同时支持不同的表现层实现的原因,比如支持Swing或Web方式的表
现层。
在逻辑层和数据层之间也是通过接口来调用,同样使得逻辑层和数据层分离开,使
得它们可以独立的扩展。尤其是数据层,可能会有很多的实现方式,比如:数据库实现、
文件实现等,就算是数据库实现,又有针对不同数据库的实现,如Oracle、DB2等等。
总之,通过面向抽象编程,三层架构的各层都能够独立的扩展和变化,而不会对其
它层次产生影响。这正好是桥接模式的功能,实现抽象和实现的分离,从而使得它们可以
独立的变化。当然三层架构不只是在一个地方使用桥接模式,而是至少在两个地方来使用
了桥接模式,一个在表现层和逻辑层之间,一个在逻辑层和数据层之间。
下面先分别看看这两个使用桥接模式的地方的程序结构,然后再综合起来看看整体
的程序结构。先看看逻辑层和数据层之间的程序结构,如图
再看看表现层和逻辑层之间的结构示意,如图
然后再把它们结合起来,看看结合后的程序结构
从广义桥接模式的角度来看,平日熟悉的三层架构其实就是在组合使用桥
接模式。从这个图还可以看出,桥接模式是可以连续组合使用的,一个桥接模式
的实现部分,可以作为下一个桥接模式的抽象部分。如此类推,可以从三层架构
扩展到四层、五层、直到N层架构,都可以使用桥接模式来组合。
如果从更本质的角度来看,基本上只要是面向抽象编写的Java程序,都可
以视为是桥接模式的应用,都是让抽象和实现相分离,从而使它们能独立的变
化。不过只要分离的目的达到了,叫不叫桥接模式就无所谓了。
桥接模式的优缺点
- 1:分离抽象和实现部分
- 2:更好的扩展性
- 3:可动态切换实现
- 4:可减少子类的个数
思考桥接模式
桥接模式的本质
桥接模式的本质是:分离抽象和实现
桥接模式对设计原则的体现
桥接模式很好的实现了开闭原则 :通常应用桥接模式的地方,抽象部分和
实现部分都是可变化的,也就是应用会有两个变化纬度,桥接模式就是找到这两
个变化,并分别封装起来,从而合理的实现OCP。
桥接模式还很好的体现了:多用对象组合,少用对象继承:
在前面的示例中,如果使用对象继承来扩展功能,不但让对象之间有很强
的耦合性,而且会需要很多的子类才能完成相应的功能,前面已经讲述过了,需
要两个纬度上的可变化数量的乘积个子类。
采用对象的组合,松散了对象之间的耦合性,不但使每个对象变得简单和
可维护,还大大减少了子类的个数,根据前面的讲述,大约需要两个纬度上的可
变化数量的和这么多个子类 。
何时选用桥接模式
- 1:如果你不希望在抽象和实现部分采用固定的绑定关系,可以采用桥接模式,来把
抽象和实现部分分开,然后在程序运行期间来动态的设置抽象部分需要用到的具
体的实现,还可以动态切换具体的实现 - 2:如果出现抽象部分和实现部分都应该可以扩展的情况,可以采用桥接模式,让抽
象部分和实现部分可以独立的变化,从而可以灵活的进行单独扩展,而不是搅在
一起,扩展一边会影响到另一边 。 - 3:如果希望实现部分的修改,不会对客户产生影响,可以采用桥接模式,客户是面
向抽象的接口在运行,实现部分的修改,可以独立于抽象部分,也就不会对客户
产生影响了,也可以说对客户是透明的 - 4:如果采用继承的实现方案,会导致产生很多子类,对于这种情况,可以考虑采用
桥接模式,分析功能变化的原因,看看是否能分离成不同的纬度,然后通过桥接
模式来分离它们,从而减少子类的数目