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

 

      来写一个大家既陌生又熟悉的设计模式，也是非常实用的一个设计模式，那就是桥接模式。

    说陌生是很多朋友并不熟悉这个设计模式，说熟悉是很多人经常见到或者是下意识的用到这个设计模式，只是不知道罢了。桥接模式是非常实用的一个模式，下面就来写写它。

   

 

 

桥接模式（Bridge）

1  场景问题

1.1  发送提示消息

        考虑这样一个实际的业务功能：发送提示消息。基本上所有带业务流程处理的系统都会有这样的功能，比如某人有新的工作了，需要发送一条消息提示他。
        从业务上看，消息又分成普通消息、加急消息和特急消息多种，不同的消息类型，业务功能处理是不一样的，比如加急消息是在消息上添加加急，而特急消息除了添加特急外，还会做一条催促的记录，多久不完成会继续催促。从发送消息的手段上看，又有系统内短消息、手机短消息、邮件等等。
        现在要实现这样的发送提示消息的功能，该如何实现呢？

1.2  不用模式的解决方案

1：实现简化版本
        先考虑实现一个简单点的版本，比如：消息先只是实现发送普通消息，发送的方式呢，先实现系统内短消息和邮件。其它的功能，等这个版本完成过后，再继续添加，这样先把问题简单化，实现起来会容易一点。
 （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的方式发送普通消息，示例代码如下：

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

  

2：实现发送加急消息

        上面的实现，看起来很简单，对不对。接下来，添加发送加急消息的功能，也有两种发送的方式，同样是站内短消息和Email的方式。
        加急消息的实现跟普通消息不同，加急消息会自动在消息上添加加急，然后再发送消息；另外加急消息会提供监控的方法，让客户端可以随时通过这个方法来了解对于加急消息处理的进度，比如：相应的人员是否接收到这个信息，相应的工作是否已经开展等等。因此加急消息需要扩展出一个新的接口，除了基本的发送消息的功能，还需要添加监控的功能，这个时候，系统的结构如图2所示：
 

 

 

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

 

 再看看Emai的方式，示例代码如下：

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所示：

                                     图3  加入发送特急消息后的系统结构示意图

        仔细观察上面的系统结构示意图，会发现一个很明显的问题，那就是：通过这种继承的方式来扩展消息处理，会非常不方便。
        你看，实现加急消息处理的时候，必须实现站内短消息和Email两种处理方式，因为业务处理可能不同；在实现特急消息处理的时候，又必须实现站内短消息和Email这两种处理方式。
        这意味着，以后每次扩展一下消息处理，都必须要实现这两种处理方式，是不是很痛苦，这还不算完，如果要添加新的实现方式呢？继续向下看吧。

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

        如果看到上面的实现，你还感觉问题不是很大的话，继续完成功能，添加发送手机消息的处理方式。
        仔细观察现在的实现，如果要添加一种新的发送消息的方式，是需要在每一种抽象的具体实现里面，都要添加发送手机消息的处理的。也就是说：发送普通消息、加急消息和特急消息的处理，都可以通过手机来发送。这就意味着，需要添加三个实现。此时系统结构如图4所示：
 

 

                                图4  加入发送手机消息后的系统结构示意图
        这下能体会到这种实现方式的大问题了吧。

3：小结一下出现的问题
        采用通过继承来扩展的实现方式，有个明显的缺点：扩展消息的种类不太容易，不同种类的消息具有不同的业务，也就是有不同的实现，在这种情况下，每个种类的消息，需要实现所有不同的消息发送方式。
        更可怕的是，如果要新加入一种消息的发送方式，那么会要求所有的消息种类，都要加入这种新的发送方式的实现。
要是考虑业务功能上再扩展一下呢？比如：要求实现群发消息，也就是一次可以发送多条消息，这就意味着很多地方都得修改，太恐怖了。
        那么究竟该如何实现才能既实现功能，又能灵活的扩展呢？
 

 

 

《研磨设计模式》一书已经上市，卓越网销售链接：
http://www.amazon.cn/%E7%A0%94%E7%A3%A8%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F-%E9%99%88%E8%87%A3/dp/B004G8P90S/ref=sr_1_1?ie=UTF8&qid=1295358211&sr=8-1

 

也可以直接在卓越网上搜索《研磨设计模式》

 

当当网的销售链接：http://product.dangdang.com/product.aspx?product_id=20994349&ref=search-0-mix

 

 

希望朋友们能给本书评评分，写点评论，多谢大家的支持！

 

 

========未完待续========

 

 

 

评论

28 楼 ximenpiaohua 2012-05-17  

写的是很不错，但是你举得例子有一种把人带进去的感觉，因为按最初的场景，明显没有继承的关系。

27 楼 Terry_zzz 2012-04-17  

很好,　比大话和阎宏的java与模式　都经典很多.　前两者空洞,　要么是牵强的比喻什么道家什么艺术,　要不是牵强复杂的例子.

支持作者chjavach 　很好的一部书,　简约但不简单的风格我很喜欢,　受益匪浅!!

26 楼 hyj1254 2010-11-05  

恩，感觉lz的文章对关键点把握得很好，在重点部分循序渐进，很透彻，和《大话》相比是个优势。

25 楼 wakuwaku 2010-11-04  

lilang0603 写道

   感觉跟伍迷写的大话设计模式是一个写作风格，只是举的列子不同而已

那本书的想法是让sb也懂设计模式，但是这个想法本身就挺sb的。

拿性质不同的事情来打比方本身就是不逻辑的事情，辩论艺术中这种类似行为直接归类于诡辩。

就事论事很好，楼主的文章很有营养。

24 楼 chjavach 2010-09-13  

lilang0603 写道

   感觉跟伍迷写的大话设计模式是一个写作风格，只是举的列子不同而已

翻了一下你说的大话,优点:风格有趣,缺点:空洞无物,最好还是不要跟他比较,呵呵.

说实话,你要是都看得明白的话,会发现这里有多少精化的东西,而不仅仅是例子!
要知道,能用实际的、合适的例子来阐述模式的理论，对模式理解的深度，实战经验的丰富，绝非举几个虚拟的例子和有趣的讲解能比的。

你别生气，一家之言，呵呵。

23 楼 lilang0603 2010-09-08  

   感觉跟伍迷写的大话设计模式是一个写作风格，只是举的列子不同而已

22 楼 icekzl 2010-09-07  

关于 java的oo设计，我觉得首先关注维度单一性变化，不要有交叉，交叉点可以考虑用 抽象类 +接口设计的模式来分离，当关注的业务需求和可预计的需求变化 被分散在不同维度中 可 实现某一接口 扩张时，设计基本上就可以通过 基础要求了。当然 这个说法是个人工作 中的感觉。是否正确 只是拿出来和高手 聊聊，说的不对还望指教。
发送方式/发送级别 两个维度领域中，发送方式 相对统一，内容+user（可以是一个封装过的对象 包括getEmail，getPhone等）  所以 采用接口 设计  。发送级别 各种发送级别有独立的业务逻辑，只是 共性逻辑是要发送 消息。所以 可以采用 抽象逻辑 封装基础发送逻辑，抽象中 引入 发送接口 句柄。达到设计 维度解耦的目的。
  这个案例 很不错。先收录下来，日后可以作为培训的案例或面试题。呵呵。感谢一下。

21 楼 ziwen 2010-09-03  

赞, 很精彩, 写得引人入胜

20 楼 only_java 2010-08-26  

我觉得这个可以用抽象工厂解决这个问题！

19 楼 木易有峰 2010-08-21  

关注。。值得学习

18 楼 leveret 2010-08-20  

由 cnblogs 追到这里，楼主才是真正的人才，能把模式说的这么清楚的人的确不多！

17 楼 wei9710 2010-08-19  

LZ 图画的漂亮！。。我期待下回分解

16 楼 ccappuccino 2010-08-18  

chjavach 写道

ccappuccino 写道

问一下：
楼主 的类图是用Eclipse的插件完成的么？如果是，插件的名字是？？

Together for eclipse

Ok 够意思 收到 Thanks

15 楼 gaodendaishu 2010-08-18  

昏倒 关键时刻没了。

14 楼 chjavach 2010-08-18  

li445970924 写道

写到关键时刻居然没了啊.. 加把劲LZ

别着急,老兄,后面的很快就会上来,呵呵

13 楼 chjavach 2010-08-18  

ccappuccino 写道

问一下：
楼主 的类图是用Eclipse的插件完成的么？如果是，插件的名字是？？

Together for eclipse

12 楼 yangguanghua 2010-08-17  

期待。。。

11 楼 zw314220663 2010-08-17  

学习  了 谢谢 楼主

10 楼 ktex263 2010-08-17  

  
对博主的技术水准 仰望 之

9 楼 li445970924 2010-08-17  

写到关键时刻居然没了啊.. 加把劲LZ