桥接模式

桥接模式是一种非常简单且非常好用的设计模式，根据网上教程举一个最简单易懂的例子：

有大，中，小三种书写字体粗细的钢笔；配上 红，黑， 蓝三种颜色墨水；使用桥接模式只需要定义六个类。

(钢笔的)Class Big, Class middle , Class Small ,

（墨水的）Class Red , Class Black , Class Blue ;

这样我们画图的时候，就可以通过不同书写字体大小的钢笔，注入不同颜色的墨水，得到 3 * 3 = 9 种 不同颜色大小的字体。

真棒，真简单，那么不用桥接模式是怎样设计呢？那就是一对一：

一种颜色配一种粗细字体的笔，要 3 * 3 = 9 支笔才能实现我们要的 9 种书写。

亲身经历：

首先声明本人不是什么天才技术大牛，也是日常上班写写业务代码，回家自己充充电，满足于一些小成就小进步的接地气的普通程序员。那是在一个非常简单的后端功能上，我做了两期，在第三期活动过来后还是那样的尿性，我就准备用桥接模式去优化的，把不同活动的定时推送内容写到一个config，通过读取不同活动的配置，跑同一套活动service代码，但是我有事回了趟家，回来的时候，一位热心肠的前端同学已经帮我全部重构完了，他用的就是一对一实现，一个活动对应了一整套的service代码；除了我写的旧的三套活动外，他帮忙新加了五个活动，每个活动都对应了三套service，别说，真的多了十五个service文件；我休假回来听说前端帮我把那些重复工作给做了还顺带优化了，非常感激不尽，当我打开代码pull了一下的时候差点晕了过去。

当然还是非常感谢他的帮忙的，那位前端对业务的理解，写的代码质量还是非常好的；主要是前后端做的事情不一样，后端同学除了业务代码，更多的更要去思考写的更好，如何提升性能这些方面。

下面献上一张经典形象的描述图：

所以我的设想其实是：桥接模式用横纵向扩展。

每一期活动不同内容（推送文案类，海报类，打点参数，活动名称编号之类）等这些可能要经常修改但是又是写死的东西，写在config配置中，更加容易读取和修改。

对于延时任务内容的推送，动态海报生成（内嵌二维码），点击触发的模版消息推送等等通用的方法，写一个abstract抽象类或interface接口；把操作的方法高度抽象出来。

这样好处在于新增活动可以不修改原有的代码，新增config配置文件，过期的活动删除掉相关的config即可。新增活动新玩法（忽然出了个抢购玩法），那就新增abstract service 或者service interface；两个纬度可以独立扩展，最重要的一点是根本不影响原来的代码，解耦，提高了service代码复用。

缺点：

1:桥接模式会使业务代码高度抽象，一定程度上加深了理解难度（肯定不够原来的一对一关系来的简单粗暴）。

2:桥接模式要在对业务逻辑非常熟悉并且是能抽象出两个或多个纬度的扩展时候才能使用；对一些新的业务，不着急使用，因为产品需求走向还不稳定，不实用。对一些service玩法没办法抽象的（一套活动是抢购，一套活动又是裂变形式）等等就不适用。

3:通过抽象实现方式和接口继承关系对类做的扩展类过多的情况下，增加修改的难度，springboot 中一个 Custom, 再扩展出CustomVo，一层层下去过多的话会增加理解难度，代码也会变得较难维护，别人接手也不好搞。

以上就是个人对桥接模式的全部看法和亲身经历；如果有说错的地方欢迎纠正一起讨论进步哈，评论必回！鞠躬！