桥梁模式（Bridge Pattern）
科普闲聊
复杂度守恒定律由Larry Tesler于1984年提出，也称泰斯勒定律（Tesler's Law）。复杂度守恒定律（Law of conservation of complexity）由Larry Tesler于1984年提出，也称泰斯勒定律（Tesler's Law）。
根据复杂度守恒定律，每个应用程序都具有其内在的、无法简化的复杂度。无论在产品开发环节还是在用户与产品的交互环节，这一固有的复杂度都无法依照我们的意愿去除，只能设法调整、平衡。
这一观点主要被应用在交互设计领域。我们不得不面对的问题是，该由谁来为这一固有的复杂度埋单。打个比方，应该由软件开发工程师花费额外的时间来使软件变得更加简单好用，还是应该让用户自己去解决软件使用中可能存在的问题？
以上出自百度百科：复杂度守恒定律 - 百度百科
如上所述，复杂度守恒定律是一个规避不掉的东西，最早的时候我接触到这个词是发出的一个提问，当时有各种大佬出来解答，大家感兴趣可以去看看。
迷惑不解,不知是何.
我了解了一下dubbo框架,很多的术语搞得是更加模糊不清.
顺便提一点,
为什么深奥的东西就是被人向往的?
将复杂的东西弄成粗浅易懂的这不是更好吗?
2018-01-15 09:04:03
但我一直以为，技术的东西，本就不复杂。让它变得复杂的是我那迫切想要得到结果的心。
学习从来都没有捷径，你只是想要速成。学的快慢是一个问题，学与不学是另一个问题，听懂掌声。
学习时间
2020年10月的某一天午饭后
“桥接模式？，那是个啥” 心中突然蹦出这么一个想法。我心血来潮，打开 Google ，输入 桥接模式 ，回车走你，等了半天。
这丝毫没有影响到我的情绪（艹），随即我快速的切换搜索引擎视图忘掉刚刚发生的这一切。又是一记回车敲出，这次，它出现了
不知道是我手不行了，还是键盘要坏了，总之模式两字没带上，出来个桥梁，想着都差不多（呸，差不多个鬼）就看看吧，顺便学习了一下桥梁的专业释义（我就是这样东西越看越多，越看越杂的！龇牙咧嘴中！）。
不行，得回过神来，继续找桥梁模式去。这怎么都一样啊，抽象化、实现化、脱耦看不懂啊，然后就是那个到处都是，其实出自菜鸟教程的图形案例。
先看看问题吧，一个图形有2种形状（圆形、矩形）和2种颜色（红色、蓝色）的时候怎么去用类表示，我啥也不说，那肯定继承啊，我这 封装、继承、多态老扎实了。
心里念着”首先有一个图形的基类，然后开始继承走起 红色的圆形、 红色的矩形、 蓝色的圆形、蓝色的矩形。“ 没毛病，一个抽象类，四个实现类，搞定。
代码写完，测一手。
@Test
void shape(){
Shape blueCircle = new BlueCircle();
Shape blueRectangle = new BlueRectangle();
Shape redCircle = new RedCircle();
Shape redRectangle = new RedRectangle();
blueCircle.create();
blueRectangle.create();
redCircle.create();
redRectangle.create();
}
蓝色の圆形
蓝色の长方形
红色の圆形
红色の长方形
感觉还可以，这时坐在我边上的大哥说了句，如果再加一种形状呢？
我：“卧槽，你啥时候来的，想要偷窥我学习？”
大哥：“先回答问题，别转移话题”
我：“再加两个类不就行了”， RedTriangle、BlueTriangle，
大哥：“也还行，如果再这基础上再加一种绿颜色呢？”
我：“额。。。再加三个类 GreenCircle、 GreenRectangle、GreenTriangle。。。（开始声音微弱）”
大哥：“再加一个椭圆呢”
“emm... 我刀呢！”
“老弟别激动，大哥帮你看看”
大哥帮忙诊断代码
大哥：“你这个是 乱用继承 导致的类爆炸晚期啊，要是不拔除对这种继承的理解，基本是废了啊”
我：“大哥我还不想放弃，救救我，咳...咳（一口老血咳出）”
大哥：“那你说说看，你都是什么时候用的继承？”
我：“多个类有共同特征的时候，会抽象出来特征，然后使用继承来扩展”
大哥：“嗯，看来你还有救，那你看你现在抽象出来的东西对吗？”
我小声嘀咕：“很多图形，抽象出来个图形，没问题啊”
大哥：“那颜色呢？颜色和图形是什么关系？”
我：“emm....，什么什么关系啊？大哥，给点提示吧"
大哥：“UML中的聚合组合我没教你么？”
我：“这个真没有”
大哥：“那这个地方我再教你一次，记着点奥。咳咳！”
大哥：“这个就是组合和聚合的意思，同时他们与主体之间的关联关系的表达。”
大哥：“现在在看你的 类爆炸 知道怎么医治了么？”
我：“我应该把颜色也抽象出来，然后使用聚合与图形进行关联！对不对！”
大哥：“还不赖嘛，你继续看吧，我忙我的去了”
重构代码
领悟了大哥的意思之后，我对代码进行了重构。
仍然将图形类抽象出来，同时将颜色作为一个接口引入，因为图形的形状和颜色本来就是两个不同的维度，所以它现在的类图应该是这个样子的。
有了类图，很快我就重构好了代码，测试一下。
完整代码关注公众号回复：“源码” 获取
当我要新增一种图形或者一个颜色时，只需要增加一个类就可以了。真香。
bridge 桥梁（接）模式
将抽象部分与它的实现部分分离，使它们都可以独立地变化。
把这绕口的东西看清楚
将抽象部分与它的实现部分分离，使他们都可以独立地变化。这句话我不知道别人能不能读的懂，就我而言，刚看到这句话实在是没有搞清楚在表达什么，我猜想其中的原因，一个是因为设计模式是搞建筑的人提出来了，另一个原因是老外写的软件设计模式。翻译成中文为了达到统一的标准，所以很多知识变得晦涩难懂。
这里在顺带提一下所谓的统一的标准，就像开放平台的接口一样。他为了有更好的扩展性，定义了统一的对外接口，以后无论哪方想要对接，都需要适应我的标准，而不是给每个人都定制化一个接口。所以知识的传播也一样，要以一定的官方标准来定义和传播，不然可能传着传着就出现了歧义。这也就是复杂度守恒定律的根本，它本身其实真的并不复杂。以上个人见解，可以无视。
在看抽象化、实现化、脱。脱。脱你妹啊脱，解耦。
因为之前有大哥的帮忙，所以很容易就理解了将抽象部分与它的实现部分分离，使它们都可以独立地变化。这句话。
就拿我刚刚学的图形的那个案例。
- 抽象部分就是图形的形状+颜色，图形它一定是有形状和颜色的。存在自身上的两个不同的维度变化
- 实现部分就是具体的形状和颜色。形状和颜色一定有具体的体现。要么圆形红色，要么方形透明。而形状又是图形本身的一部分，所以可以跟在主体后通过继承进行变化。颜色可以独立出去进行单独的扩展。
独立的变化就是讲到抽象部分和实现部分的两个实现
- 抽象部分的一个变化就是通过一个矩形类继承图形抽象类。同时完善一个构造函数，这是对抽象部分的矫正或者完备。
- 实现部分的变化遵循了里式替换与抽象部分的关联又根据依赖倒置原则设计。所以实现部分可以在自己的接口定义范畴能进行自由变化，同时又可以与抽象部分进行关联（桥接）
我试着把晦涩的东西简化一下
一个对象的多个维度状态独立变化时，将其通过类组合的方式进行关联，使其每个维度自由变化，降低与主体的耦合。
桥接模式类图 📌
代码 📄
完整代码关注公众号回复：“源码” 获取
总结 🐱💻
哎呀，这个桥接模式我是万万没想到它会是这个样子。同样又是学完不知道在哪用的一种模式，但这就是我放弃学习的理由？那可真是太可笑了。
- 当一个对象内存在多个维度多种状态时，可以使用桥接模式解耦，以防新增维度状态时导致 类爆炸
- 维度的体现可以延迟到使用阶段，比如上述例子，颜色被分离出去，当需要具体对象时，在通过 set 方法对维度赋值（回复源码，获取全部源码和文章原稿）
桥接模式的好处大家都看在眼里，记在心里。用了桥接模式首先解决的就是因为乱用继承导致的类爆炸问题，同时无论之后怎么扩展类，都只需要在对应维度维护新的实现就可以了，降低了对象间的耦合。
不好的地方，整个设计模式的缺点全都包含这一条： 增加了系统的复杂性，对系统设计的理解多了一层内容。维护的类变多了。 这更能体现出一劳永逸的感觉，先吃苦，后舒坦。其实对于桥接模式还有一点，就是需要你能正确的去划分出一个对象的多维度状态，不然又成了“手里拿个锤子，看什么都像钉子”的感觉了。
打工人的早高峰
今天的公交车一点都不挤！就是下车的时候鸡蛋不知道咋回事碎了！还好是鸡蛋碎了，听懂掌声。
其他设计模式：点击查看
