我的书签
添加书签
移除书签24.1 场 景 问 题
24.1.1 发送提示消息
考虑这样一个实际的业务功能：发送提示消息。基本上所有带业务流程处理的系统都会有这样的功能，比如某人有新的工作了，需要发送一条消息提示他。
从业务上看，消息又分成普通消息、加急消息和特急消息多种，不同的消息类型，业务功能处理是不一样的，比如加急消息是在消息上添加加急，而特急消息除了添加特急外，还会做一条催促的记录，多久不完成会继续催促；从发送消息的手段上看，又有系统内短消息、手机短消息、邮件等。
24.1.2 不用模式的解决方案
1．实现简化版本
先考虑实现一个简单点的版本，比如，消息只是实现发送普通消息，发送的方式呢，只实现系统内短消息和邮件。其他的功能，等这个版本完成后，再继续添加。这样先把问题简单化，实现起来会容易一点。
由于发送普通消息会有两种不同的实现方式，为了让外部能统一操作，因此，把消息设计成接口，然后由两个不同的实现类分别实现系统内短消息方式和邮件发送消息的方式。此时系统结构如图24.1所示。
图24.1 简化版本的系统结构示意图
下面看看大致的实现示意。
（1）先来看看消息的统一接口。示例代码如下：
（2）再来分别看看两种实现方式。这里只是为了示意，并不会真的去发送E-mail和站内短消息。
先看看站内短消息的方式。示例代码如下：
同样地，实现以E-mail的方式发送普通消息。示例代码如下：
2．实现发送加急消息
上面的实现看起来很简单，对不对？接下来，添加发送加急消息的功能，也有两种发送的方式，同样是站内短消息和E-mail的方式。
加急消息的实现不同于普通消息。加急消息会自动在消息上添加加急，然后再发送消息；另外加急消息会提供监控的方法，让客户端可以随时通过这个方法来了解对于加急消息处理的进度，比如，相应的人员是否接收到这个信息，相应的工作是否已经开展等。因此加急消息需要扩展出一个新的接口，除了基本的发送消息的功能，还需要添加监控的功能。这个时候，系统的结构如图24.2所示。
图24.2 加入发送加急消息后的系统结构示意图
（1）先看看扩展出来的加急消息的接口。示例代码如下：
（2）相应的实现方式还是发送站内短消息和E-mail两种，同样需要两个实现类来分别实现这两种方式。
先看看站内短消息的方式。示例代码如下：
再看看E-mail的方式。示例代码如下：
事实上，在实现加急消息发送的功能上，可能会使用前面发送不同消息的功能，也就是让实现加急消息处理的对象继承普通消息的相应实现。但这里为了让结构简单、清晰一点，所以没有这样做。
24.1.3 有何问题
上面这样实现，好像也能满足基本的功能要求，可是这么实现好不好呢？有没有什么问题呢？
咱们继续向下来添加功能实现。为了简洁，就不再进行代码示意了，通过实现的结构示意图就可以看出实现上的问题。
1．继续添加特急消息的处理
特急消息不需要查看处理进程，只要没有完成，就直接催促，也就是说，对于特急消息，在普通消息的处理基础上，需要添加催促的功能。而特急消息和催促的发送方式，相应的实现方式还是发送站内短消息和E-mail两种。此时系统的结构如图24.3所示。
仔细观察上面的系统结构示意图，会发现一个很明显的问题，那就是通过这种继承的方式来扩展消息处理，会非常不方便。
会看到在实现加急消息处理的时候，必须实现站内短消息和E-mail两种处理方式，因为业务处理可能不同；在实现特急消息处理的时候，又必须实现站内短消息和E-mail这两种处理方式。
这意味着，以后每次扩展一下消息处理，都必须要实现这两种处理方式，是不是很痛苦？这还不算完，如果要添加新的实现方式呢？继续向下看吧。
图24.3 加入发送特急消息后的系统结构示意图
2．继续添加发送手机消息的处理方式
如果看到上面的实现，你还感觉问题不是很大的话，继续完成功能，添加发送手机消息的处理方式。
仔细观察现在的实现，如果要添加一种新的发送消息的方式，是需要在每一种抽象的具体实现中，都要添加发送手机消息的处理的。也就是说，发送普通消息、加急消息和特急消息的处理，都可以通过手机来发送。这就意味着，需要添加三个实现。此时系统结构如图24.4所示。
图24.4 加入发送手机消息后的系统结构示意图
现在体会到这种实现方式的大问题了吧。
3．小结一下出现的问题
采用通过继承来扩展的实现方式，有个明显的缺点，扩展消息的种类不太容易。不同种类的消息具有不同的业务，也就是有不同的实现，在这种情况下，每个种类的消息，需要实现所有不同的消息发送方式。
更可怕的是，如果要新加入一种消息的发送方式，那么会要求所有的消息种类都要加入这种新的发送方式的实现。
要是考虑业务功能上再扩展一下呢？比如，要求实现群发消息，也就是一次可以发送多条消息，这就意味着很多地方都得修改，太恐怖了。
