桥接模式-1

柔情只为你懂 2021-09-16 10:10 147阅读 0赞

在学习设计模式时，发现桥接模式是一个比较好用，但是又难以理解的模式，在网上找到了这篇文章，自认为写得还不错，转载一下。

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

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

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

# 桥接模式（Bridge）    #

## 1  场景问题    ##

### 1.1  发送提示消息 ###

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

###    1.2  不用模式的解决方案    ###

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

![542e912d-adc0-348d-af47-30d7388beea8.png][]  
 图1  简化版本的系统结构示意图

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

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

Java代码   ![收藏代码][icon_star.png]

1.  /\*\* 
2.   \* 消息的统一接口 
3.   \*/  
4.  **public** **interface** Message \{  
5.      /\*\* 
6.       \* 发送消息 
7.       \* @param message 要发送的消息内容 
8.       \* @param toUser 消息发送的目的人员 
9.       \*/  
10.     **public** **void** send(String message,String toUser);  
11. \}

（3）再来分别看看两种实现方式，这里只是为了示意，并不会真的去发送Email和站内短消息，先看站内短消息的方式，示例代码如下：

Java代码   ![收藏代码][icon_star.png]

1.  /\*\* 
2.   \* 以站内短消息的方式发送普通消息 
3.   \*/  
4.  **public**  **class** CommonMessageSMS **implements** Message\{  
5.      **public** **void** send(String message, String toUser) \{  
6.          System.out.println("使用站内短消息的方式，发送消息'"  
7.  \+message+"'给"\+toUser);  
8.      \}  
9.  \}

同样的，实现以Email的方式发送普通消息，示例代码如下：

Java代码   ![收藏代码][icon_star.png]

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

**2：实现发送加急消息**

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

![a10b960a-bd6f-306c-850c-a1dea5f7f897.gif][]

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

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

Java代码   ![收藏代码][icon_star.png]

1.  /\*\* 
2.   \* 加急消息的抽象接口 
3.   \*/  
4.  **public** **interface** UrgencyMessage **extends** Message\{  
5.      /\*\* 
6.       \* 监控某消息的处理过程 
7.       \* @param messageId 被监控的消息的编号 
8.       \* @return 包含监控到的数据对象，这里示意一下，所以用了Object 
9.       \*/  
10.     **public** Object watch(String messageId);  
11. \}

（2）相应的实现方式还是发送站内短消息和Email两种，同样需要两个实现类来分别实现这两种方式，先看站内短消息的方式，示例代码如下：

Java代码   ![收藏代码][icon_star.png]

1.  **public** **class** UrgencyMessageSMS **implements** UrgencyMessage\{  
2.      **public** **void** send(String message, String toUser) \{  
3.          message = "加急："\+message;  
4.          System.out.println("使用站内短消息的方式，发送消息'"  
5.  \+message+"'给"\+toUser);  
6.      \}  
7.    
8.      **public** Object watch(String messageId) \{  
9.          //获取相应的数据，组织成监控的数据对象，然后返回         
10.         **return** **null**;  
11.     \}     
12. \}

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

Java代码   ![收藏代码][icon_star.png]

1.  **public** **class** UrgencyMessageEmail **implements** UrgencyMessage\{  
2.      **public** **void** send(String message, String toUser) \{  
3.          message = "加急："\+message;  
4.          System.out.println("使用Email的方式，发送消息'"  
5.  \+message+"'给"\+toUser);  
6.      \}  
7.      **public** Object watch(String messageId) \{  
8.          //获取相应的数据，组织成监控的数据对象，然后返回         
9.          **return** **null**;  
10.     \}     
11. \}

（3）事实上，在实现加急消息发送的功能上，可能会使用前面发送不同消息的功能，也就是让实现加急消息处理的对象继承普通消息的相应实现，这里为了让结构简单一点，清晰一点，所以没有这样做。

###    1.3  有何问题    ###

上面这样实现，好像也能满足基本的功能要求，可是这么实现好不好呢？有没有什么问题呢？  
        咱们继续向下来添加功能实现，为了简洁，就不再去进行代码示意了，通过实现的结构示意图就可以看出实现上的问题。  
**1：继续添加特急消息的处理**  
        特急消息不需要查看处理进程，只要没有完成，就直接催促，也就是说，对于特急消息，在普通消息的处理基础上，需要添加催促的功能。而特急消息、还有催促的发送方式，相应的实现方式还是发送站内短消息和Email两种，此时系统的结构如图3所示：  
  
  
![583c71b6-d076-33e7-9d2f-255f7d075f8a.gif][]

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

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

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

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

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

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

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

[542e912d-adc0-348d-af47-30d7388beea8.png]: /images/20210726/65dcbb60624b4e5487a3cbef147279d2.png
[icon_star.png]: /images/20210726/7c52290ec67e42ba9b9b535d50a9d3e2.png
[a10b960a-bd6f-306c-850c-a1dea5f7f897.gif]: /images/20210726/36b6065935cd4e5db02f9179689c9179.png
[583c71b6-d076-33e7-9d2f-255f7d075f8a.gif]: /images/20210726/9e019f5c0d8844db9613305fd314c74d.png
[9d003e79-5a28-3c15-a05c-66948f630c64.gif]: /images/20210726/68ac7034eae4452da3f1fe25ef259ff4.png