研磨设计模式之桥接模式-1(转)

?

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

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

?

?

?

桥接模式（Bridge）

1? 场景问题

1.1? 发送提示消息

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

1.2? 不用模式的解决方案

1：实现简化版本
??????? 先考虑实现一个简单点的版本，比如：消息先只是实现发送普通消息，发送的方式呢，先实现系统内短消息和邮件。其它的功能，等这个版本完成过后，再继续添加，这样先把问题简单化，实现起来会容易一点。
?（1）由于发送普通消息会有两种不同的实现方式，为了让外部能统一操作，因此，把消息设计成接口，然后由两个不同的实现类，分别实现系统内短消息方式和邮件发送消息的方式。此时系统结构如图1所示：

?

?图1? 简化版本的系统结构示意图

?

下面看看大致的实现示意。

（2）先来看看消息的统一接口，示例代码如下：

?

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

（1）先看看扩展出来的加急消息的接口，示例代码如下：

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

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

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

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

?

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

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

?

?

?

?

?

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

?

转载自：http://chjavach.iteye.com/blog/738056

?