桥接模式

解决的问题

当一个类存在多个维度的变化时，使用桥接模式可以增加类的灵活性。该模式体现了优先使用组合/聚合，而不是继承。

实例

考虑记录日志的类，从日志输出终端维度考虑，可以有控制台、文件、网络socket；而从日志输出的格式维度考虑，可以按xml格式输出，也可以按json格式输出，或者简单的字符串格式输出。如果所有的日志都来自于继承自Log接口，那么上述场景的类图可能为：

可以看到，此时实现类FileLogger与接口是紧耦合在一起的；如果现在增加一种将日志存入redis缓存的功能RedisLogger；那么势必会打乱类的继承结构，导致类爆炸。设计模式的思想就是封装变化，这里的变化来自两个维度终端类型和日志格式，只不过目前使用继承封装这两种变化导致结构僵化不利于扩展。下面先介绍桥接模式，然后分析JDK的logging是如何解决此问题的。

桥接模式

Abstraction：抽象类，它持有Implementor；抽象类有具体的实现类，它调用Implementor的方法完成高层次的功能，例如日志输出。

Implementor：实现类接口，它定义了系统中某一个维度的变化，它只提供基本的功能，被Abstraction调用。

通过这种组合方式，将抽象与实现解耦，Abstraction和Implementor可以独立变化增加类型，而不互相影响。当系统有3个维度的变化时，就再增加一个维度的Implementor’并在Abstraction中增加该接口的引用。

JDK Logging分析

使用Logging的代码很简单

Logger logger = Logger.getLogger("com.test.logger");
logger.info("message");

在Logger内部，会将日志封装为LogRecord，并把请求委派给Handler进行处理，这里的Handler就是抽象。

Handler是抽象父类，完成打印日志功能；在Handler中有Formatter引用，定义了日志格式。整体类结构图如下：

Handler类层次封装了输出终端的变化，分别有Console、File、Socket。Formatter类封装日志格式变化，分别有简单字符串格式和XML输出格式。

下面看看publish方法：

publish在输出日志之前会调用getFormatter().format()对日志进行格式化；而在初始化各种Handler时会设置具体使用哪个Formatter。

完成日志输出的是Writer，它也是在初始化Handler时创建的。

SocketHandler创建Writer：

ConsoleHandler创建Writer：

FileHandler创建Writer：

其实Logging解决此问题的本质是，在Handler中持有Writer和Formatter两个引用，用Writer封装终端维度的变化，在编译时确定终端类型；而Formatter封装格式的变化，但在运行时通过set()动态决定日志格式，从而解决多重继承类爆炸的问题。