研磨设计模式之桥接模式-2

chjavach

浏览: 464698 次
性别:
来自: 北京

最近访客更多访客>>

zuiniao123

john2522

potaly

czldl

博主相关

博客

微博

相册

留言

关于我

文章分类

社区版块

存档分类

博客分类：

研磨设计模式

设计模式 Mobile 敏捷开发数据结构 IDEA

2 解决方案

2.1 桥接模式来解决

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

（1）桥接模式定义
将抽象部分与它的实现部分分离，使它们都可以独立地变化。

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

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

        现在出现问题的根本原因，就在于消息的抽象和实现是混杂在一起的，这就导致了，一个纬度的变化，会引起另一个纬度进行相应的变化，从而使得程序扩展起来非常困难。
        要想解决这个问题，就必须把这两个纬度分开，也就是将抽象部分和实现部分分开，让它们相互独立，这样就可以实现独立的变化，使扩展变得简单。
        桥接模式通过引入实现的接口，把实现部分从系统中分离出去；那么，抽象这边如何使用具体的实现呢？肯定是面向实现的接口来编程了，为了让抽象这边能够很方便的与实现结合起来，把顶层的抽象接口改成抽象类，在里面持有一个具体的实现部分的实例。
        这样一来，对于需要发送消息的客户端而言，就只需要创建相应的消息对象，然后调用这个消息对象的方法就可以了，这个消息对象会调用持有的真正的消息发送方式来把消息发送出去。也就是说客户端只是想要发送消息而已，并不想关心具体如何发送。

2.2 模式结构和说明

桥接模式的结构如图6所示：

                                    图6 桥接模式的结构示意图
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所示

                     图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方式的实现，示例代码如下：

/**
 * 以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("请喝一杯茶", "小李");
	}
}

运行结果如下：

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

前面三条是使用的站内短消息，后面三条是使用的手机短消息，正确的实现了预期的功能。看来前面的实现应该是正确的，能够完成功能，且能灵活扩展。

未完待续

查看图片附件

89
顶

7
踩

分享到：

研磨设计模式之桥接模式-3 | 研磨设计模式之桥接模式-1

2010-08-23 07:52
浏览 13058
评论(39)
分类:企业架构
查看更多

39 楼 ruzhefeng 2011-01-05

扩展消息处理类，在原有方法上前或后追加内容，可以AOP也行哈

38 楼 seawenzhu 2010-09-15

看过的最好的博客

37 楼 sunce 2010-09-09

之前看了两遍，今天过来，又看一遍，越看越有味道，，呵呵

36 楼 salever 2010-09-08

chjavach 写道

salever 写道

例子很精彩，首先赞一个，下面是一点疑问：
示例中，消息类型和发送方式是两个相对独立的维度，这里的确用Bridge模式最合适不过了，它们两个同属于行为抽象(关于抽象，理解可能不太一样)，也就是不同的策略之间的组合。

发送消息的方式：Email、手机等，它们有各自的实现
发送类型：普通，加急，特急，这里他们的行为也各自不同，比如加急需要watch，而特急需要hurry

设计的时候首先将这两种策略(分别关注底层硬件实现和发送方式)分离，然后用一个桥梁连接起来，已组成新的消息发送机制，可以这么理解么？

我看了一下Uncle Bob的《敏捷开发》，里面有一个Bridge的例子，不过觉得讲得不够好，也许是中文翻译的缘故。

Bridge是比较复杂的模式之一了，能用手头的例子细细讲解，博主功力可见一斑！

salever 兄,你写道"设计的时候首先将这两种策略(分别关注底层硬件实现和发送方式)分离，然后用一个桥梁连接起来，已组成新的消息发送机制，可以这么理解么？"

我的回答是,可以这么理解,你说的是对的,但是还想额外帮你补充一点,那就是:
这两种策略或者是抽象并不是孤立的,是有关系的,通常情况下是一种策略或者抽象的实现需要使用另外一种策略或抽象的实现,从而会形成抽象间需要组合的场景,这种适合使用桥接模式。
如果两种策略或者是抽象是孤立存在的话,那就没有桥接的存在了。

对，桥接的精华就在这里吧。

35 楼 chjavach 2010-09-08

salever 写道

34 楼 salever 2010-09-07

33 楼 chjavach 2010-09-01

superheizai 写道

一个想法跟楼主请教，就是楼上有位同学说的抽象工厂与这里的桥模式。
楼上同学说了产品族与产品族的产品。我觉得也是可以的，只不过，不是用在这里。抽象工厂说的是构建型模式，更多的是为了产品族的生成与构建。而我们的桥模式是用来对产品进行类层次结构与扩展性方面的设计。我觉得这二者的目的本来就是不一样的。也就是说，我们可以把抽象工厂与桥模式组合起来使用，一个用来组织类层次及其关系，一个用来生成实例。
另外想说的是，楼上其它同学提及的装饰器与代理模式，从看其它书我觉得，二者的类图很相近，几乎相同，只是出发点不一样：一个是为了动态添加功能，一个是为了实现其它类型的代理。
是不是这样子的呢？

你描述的是对的,只是对代理的认识有些问题,代理其实有很多种,最典型的一种就是代理访问,而不是你描述的"为了实现其它类型的代理".
代理模式的定义就是"为其它对象提供一种代理以控制对这个对象的访问".当然代理有很多种,比如:虚代理、远程代理、保护代理......

32 楼 superheizai 2010-08-31

31 楼 waykingeye 2010-08-31

膜拜。。。

30 楼 juda 2010-08-30

楼主给解释下为什么这种模式叫“桥式”，谢谢，顶大牛。

29 楼 cyan747 2010-08-27

前些天看bridge模式一直搞不太清楚，看了楼主的博文很有收获

28 楼 liusu 2010-08-27

Great. Sorry i can't input chinese!

27 楼 only_java 2010-08-26

chjavach 写道

only_java 写道

[img]
http://dl.iteye.com/upload/attachment/297208/37c607c1-0be1-3a85-8498-ed23e9e7331a.gif
[/img]
一看到这个图就让我想起了抽象工厂模式，普通消息，加急消息，特急消息是“产品等级结构”，而email,mobile,站内信等则是“产品族”。可以把email,mobile等认为成一个个平台，这样就成了各种消息在各个平台上发送！

    虽然有些相似,但是这个应用使用抽象工厂模式是不妥的.
    抽象工厂模式的定义:提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。
     对于抽象工厂模式的理解要注意几点:
    1：抽象工厂模式的目的是为了创建对象
     2：抽象工厂模式创建的对象一定是相关或者是相互依赖的对象
     3：抽象工厂模式创建的对象通常是构成其它对象所需要的某个部分

    来看这里的问题，email,mobile,站内信等发送消息的方式，本身是没有相关或是相互联系的，完全是独立的实现。
    同样来看普通消息，加急消息，特急消息这边，虽然他们有一定的等级关系，但是并不等同于抽象工厂模式的产品等级结构。
    其实，最重要的要重实现的目的上来判断，这里最主要的问题是：消息类型和发送消息的方式是完全独立的，需要独立扩展，但是他们之间又有联系，而且这个联系所对应的关系并不确定，因此需要使用桥接来分离这两个部分，使得他们可以独立扩展而又方便组合使用。

PS：你看待问题的角度不错，很有意思。

仔细看了下，发现你的方法确实不错，即可以很方便的扩展消息类型，也可以很方便的扩展消息平台。而且只需要添加相应的方法，无需修改原有的方法！

26 楼 only_java 2010-08-26

http://dl.iteye.com/upload/picture/pic/70402/66a0975a-dfcf-31fa-8059-b6c804c4f6ca.gif

抽象工厂扩展“产品族”（即发送消息的平台email,mobile等），非常简单！但要扩展“产品等级结构”（即是发送普通消息，还是特急消息等）就比较麻烦！

注：产品族，产品等级结构是<<java与模式>>里面定义的术语，我也找不出啥好的词来形容

25 楼 chjavach 2010-08-26

only_java 写道

24 楼 only_java 2010-08-26

23 楼 rather_lonely 2010-08-26

楼主是真正用心在写

22 楼繁花碎落 2010-08-26

:x 11111111111111

21 楼 chjavach 2010-08-26

lwp2000 写道

LZ能把goF的那本设计模式发一本给我吗？
邮箱：renjianrenjian1@163.com

不好意思,我买的是书,2000年买的,已经看了10年了,呵呵,电子版的你在网上找找吧,好象有

20 楼 white182517 2010-08-25

将模式和现实场景联系起来讲述更能容易让人理解。

期待楼主更精彩的下文，能更新再快些就好了！！

发表评论

您还没有登录,请您登录后再发表评论

最近访客更多访客>>

博主相关

文章分类

社区版块

存档分类

最新评论