设计模式-结构型-桥接模式

两种理解方式

“将抽象和实现解耦，让它们可以独立变化。”
“一个类存在两个（或多个）独立变化的维度，我们通过组合的方式，让这两个（或多个）维度可以独立进行扩展。”通过组合关系来替代继承关系，避免继承层次的指数级爆炸。—— 组合优于继承

应用举例

API 接口监控告警的例子：根据不同的告警规则，触发不同类型的告警。告警支持多种通知渠道，包括：邮件、短信、微信、自动语音电话。通知的紧急程度有多种类型，包括：SEVERE（严重）、URGENCY（紧急）、NORMAL（普通）、TRIVIAL（无关紧要）。不同的紧急程度对应不同的通知渠道。比如，SERVE（严重）级别的消息会通过“自动语音电话”告知相关人员。

常规实现方法是将判断逻辑写在 Notification 类中，这样会出现大量的 if-else 子句。如下所示:

Notification 类的代码实现有一个最明显的问题，那就是有很多 if-else 分支逻辑。实际上，如果每个分支中的代码都不复杂，后期也没有无限膨胀的可能（增加更多 if-else 分支判断），那这样的设计问题并不大，没必要非得一定要摒弃 if-else 分支逻辑。

不过，Notification 的代码显然不符合这个条件。因为每个 if-else 分支中的代码逻辑都比较复杂，发送通知的所有逻辑都扎堆在 Notification 类中。我们知道，类的代码越多，就越难读懂，越难修改，维护的成本也就越高。很多设计模式都是试图将庞大的类拆分成更细小的类，然后再通过某种更合理的结构组装在一起。

桥接优化

针对 Notification 的代码，我们将不同渠道的发送逻辑剥离出来，形成独立的消息发送类（MsgSender 相关类）。其中，Notification 类相当于抽象，MsgSender 类相当于实现，两者可以独立开发，通过组合关系（也就是桥梁）任意组合在一起。所谓任意组合的意思就是，不同紧急程度的消息和发送渠道之间的对应关系，不是在代码中固定写死的，我们可以动态地去指定（比如，通过读取配置来获取对应关系）

这样在使用的时候就可以自由的组合了，不同的通知组合不同的发送渠道，例如：

telphoneMsgSander = new TelephoneMsgSender()  // 定义一个短信渠道
normalNotification = NormalNotification(telphoneMsgSander)  // 普通级别使用短信渠道
normalNotification.notify()  // 通知
    
    
serverNotification = ServerNotification(telphoneMsgSander)  // 验证级别使用短信渠道
serverNotification.notify()  // 通知

可见，桥接模式体现了组合优于继承的思想，通过将不同的功能类进行灵活的组合，来去除繁杂冗余的条件判断等逻辑。还有一些生活中的场景，例如不同的 TV 端和不同的遥控器，不同的图形可以涂抹不同的颜料。这些场景都是灵活组合的场景。