设计模式实际工作实践——桥梁模式

设计模式实际工作实践——桥梁模式

阅读引导：

1、多维度分析。

2、适用于有可能多个维度组合形成一个场景，并且各个维度可能分别演化的场景

3、为自己工作，为自己的系统工作，做自己的老板，形成正循环：打磨当前工作的核心关键能力——>高效能工作——>更多时间打磨自己的系统——>更高效能工作——>打磨下个层次工作的核心关键能力……

4、核心竞争力，是指你拥有的（独特的）知识经验组合，经过你思维逻辑的组织梳理，在实践中产生无可替代的价值。打造自己的TMS系统（T：专业技术；M：沟通管理、S：行业解决方案），利用复利效应，让系统为自己工作。

为什么初学者有时候无法理解设计模式？

因为没有遇到过问题，设计模式实际上是为了解决某种场景下的问题产生的优雅解决方案。

所以看了很多设计模式的书，由概念出发，反向举例子与人的认知方向正好冲突。

设计模式的学习，应该通过问题引出，学习者有了自己的实现之后，再去给出设计模式的实现，经过对比才会让学习者认识深刻，有一种思维上的爽快感！

并且，设计模式作为一种解决问题的模式工具，为什么每本设计模式书里面都要将类图画的那么复杂？

不应该掌握其解决问题的适用场景，如果到了使用的时候，再去翻看一下书看下怎么实现不就可以了吗？

大脑用来思考，不是用来存储。

中国话叫做：君子不器。

转入正题

先给一个结论：

桥梁模式，解决的是某个场景下，有多个维度分别演化的问题

首先来看一下两个问题：

问题1：发送通知场景

在工作开发中，经常遇到一个业务场景完成之后，需要发送多种通知，例如短信通知、邮件通知、微信通知、app通知……而通知分为一般通知、紧急通知等等，随着业务发展、科技发展，通知方式、通知类型都有可能发生变化。如何设计这个通知模块？

读者可以先思考一下自己如何实现。

我们首先进行维度分析（OOA）看一下一下场景描述。

这段描述里面有两个关键维度：通知类型、通知渠道。

维度1：通知类型，有可能是一般通知、紧急通知……

维度2：通知渠道，有可能包含短信、邮件、微信……

这两个维度，每一个都是有可能单独变化的。

而两者之间，有可能随意组合扩展，例如现在业务要求通过短信发送一般通知，而考虑到成本，后面也许将会变化成通过微信发送通知。

简单的类图如下，核心原理就是拆解成单一维度，然后统一组装，最大化的解耦：

问题2：适配多种协议类型请求报文场景

一个业务系统，一般需要与外部各种公司系统直连，例如对接蚂蚁金服、对接腾讯微信……

每一个外部系统的报文协议都不一样。

一种最初级的简陋方案是：每次都在web.xml中加上映射路径（或者controller中加入），每一个路径都特殊处理。

但是，这种复杂的变动情况，肯定不符合程序员的审美观。

面向对象开发的一个大原则就是：

封装变化

对于这种场景，再进行一下维度分析。

我们可以看到，一次请求也有两种维度：

通讯协议维度，例如HTTP、SOCKET、MQ……

报文协议维度，webservice的soap报文、json格式报文、xml格式报文、定长字段格式报文等等

而我们内部系统，通常有一个自己的统一模型（假设叫做：RequestMsg），我们要做的是要支持各种通讯协议、各种报文协议的组合变幻。

当然，如果企业内部有网关的话，这一层的转换处理可能是在网关进行处理了，业务系统只需要处理业务即可了。

对于此部分的桥接模式处理类图如下：