3.1 《硬啃设计方式》第10章 麻烦的日志记录 - 桥模式(Bridge Pattern)

3.1 《硬啃设计模式》第10章 麻烦的日志记录 - 桥模式(Bridge Pattern)

某日志组件既支持输出到文本文件，也支持输出到数据库文件，它的设计如下：

 

很酷的设计，如果哪天要输出到Oracle，增加一个OracleLog类就搞定了！

问：如果要加密信息，咋办呢？
答：那还不容易，在相应的XXLog类中写加密。或者将接口换成抽象类，将加密算法写进去就行了。

问：某些情况下可能需要加密，某些情况可能不需要，加密的算法也可能需要更换，加密最好不要和具体的输出方式绑死。有什么好办法？
答：......

思考：
加密和输出方式两者应该不太相干，用怎样的加密方法不应该影响到用什么输出方式，同样用怎样的输出方式也不应该影响到用什么办法加密。
我们现在要解决的问题是如何让加密、输出方式这两组功能能组合在一起，又不会互相耦合。

如果发现需要将两组功能组合来用时，可以考虑用“桥”将这两组功能组合起来。下面是应用了桥模式之后的设计：

 

如果日志想用MD5加密，并保存到Oracle中，则可以写以下代码：
Message m = new MD5_Message(new OracleLog);
m.log("...这里是日志内容...");

如果不想加密，并想输出到TXT文件中，则写如下代码：
Message m = new NoEncryptMessage(new TxtLog);
m.log("..这里是日志内容...");

怎样，简单不？加密与输出方式可以任意组合！我们仔细分析一下设计：
1.该类图的右半部分和之前的是一样的，而多出来的是左半部分。
2.Message抽象类有指向ILog的引用，通过构造函数来传入。
3.每个继承Message的类都需要实现Log()方法，该方法的写法是整个设计精妙的关键之处，要先写加密的代码，然后调用所引用的Log类的Log()方法。
4.加密、输出方式分别被抽象成Message、ILog，这样就将两者分离了可单独发展，而Message还有指向ILog的引用，这是两者的桥梁，桥模式的名字就是这样来的了。

下面看看桥模式的类图：

 

这个图稍微比较难懂，很多书籍都会说桥模式是将“抽象”与“实现”分离并可独立扩展，这样的说法我自己也觉得超难理解。
我觉得如果理解不了这样的说法，就不要管“抽象”和“实现”的说法了，就认为将两组功能分离并可以结合使用的一种设计方法，上述的例子还是比较好理解的，按照这样的设计思路，其实可以将Log和Message换过来写，可以是Log引用Message。