桥接模式：你这个是“乱用继承”导致的类爆炸晚期啊

本文主要是介绍桥接模式：你这个是“乱用继承”导致的类爆炸晚期啊，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

在这里插入图片描述

科普闲聊

复杂度守恒定律由Larry Tesler于1984年提出，也称泰斯勒定律（Tesler’s Law）。复杂度守恒定律（Law of conservation of complexity）由Larry Tesler于1984年提出，也称泰斯勒定律（Tesler’s Law）。
根据复杂度守恒定律，每个应用程序都具有其内在的、无法简化的复杂度。无论在产品开发环节还是在用户与产品的交互环节，这一固有的复杂度都无法依照我们的意愿去除，只能设法调整、平衡。

这一观点主要被应用在交互设计领域。我们不得不面对的问题是，该由谁来为这一固有的复杂度埋单。打个比方，应该由软件开发工程师花费额外的时间来使软件变得更加简单好用，还是应该让用户自己去解决软件使用中可能存在的问题？

以上出自百度百科：复杂度守恒定律 - 百度百科

如上所述，复杂度守恒定律是一个规避不掉的东西，最早的时候我接触到这个词是发出的一个提问，当时有各种大佬出来解答，大家感兴趣可以去看看。

到底什么是RPC?远程调用有什么好处?

迷惑不解,不知是何.
我了解了一下dubbo框架,很多的术语搞得是更加模糊不清.
顺便提一点,
为什么深奥的东西就是被人向往的?
将复杂的东西弄成粗浅易懂的这不是更好吗?2018-01-15 09:04:03

但我一直以为，技术的东西，本就不复杂。让它变得复杂的是我那迫切想要得到结果的心。

学习从来都没有捷径，你只是想要速成。学的快慢是一个问题，学与不学是另一个问题，听懂掌声。

学习时间

2020年10月的某一天午饭后

“桥接模式？，那是个啥” 心中突然蹦出这么一个想法。我心血来潮，打开 Google ，输入 桥接模式 ，回车走你，等了半天。

这丝毫没有影响到我的情绪~~（艹）~~，随即我快速的切换搜索引擎视图忘掉刚刚发生的这一切。又是一记回车敲出，这次，它出现了

不知道是我手不行了，还是键盘要坏了，总之模式两字没带上，出来个桥梁，想着都差不多（呸，差不多个鬼）就看看吧，顺便学习了一下桥梁的专业释义（我就是这样东西越看越多，越看越杂的！龇牙咧嘴中！）。

不行，得回过神来，继续找桥梁模式去。这怎么都一样啊，抽象化、实现化、脱耦看不懂啊，然后就是那个到处都是，其实出自菜鸟教程的图形案例。

图片来源：https://www.runoob.com/w3cnote/bridge-pattern2.html

先看看问题吧，一个图形有2种形状（圆形、矩形）和2种颜色（红色、蓝色）的时候怎么去用类表示，我啥也不说，那肯定继承啊，我这 封装、继承、多态老扎实了。

心里念着”首先有一个图形的基类，然后开始继承走起 红色的圆形、 红色的矩形、 蓝色的圆形、蓝色的矩形。“ 没毛病，一个抽象类，四个实现类，搞定。

代码写完，测一手。

    @Testvoid 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中的聚合组合我没教你么？”

我：“这个真没有”

大哥：“那这个地方我再教你一次，记着点奥。咳咳！”

uml

大哥：“这个就是组合和聚合的意思，同时他们与主体之间的关联关系的表达。”

大哥：“现在在看你的 类爆炸 知道怎么医治了么？”

我：“我应该把颜色也抽象出来，然后使用聚合与图形进行关联！对不对！”

大哥：“还不赖嘛，你继续看吧，我忙我的去了”

重构代码

领悟了大哥的意思之后，我对代码进行了重构。

仍然将图形类抽象出来，同时将颜色作为一个接口引入，因为图形的形状和颜色本来就是两个不同的维度，所以它现在的类图应该是这个样子的。

有了类图，很快我就重构好了代码，测试一下。

完整代码关注公众号回复：“源码” 获取

当我要新增一种图形或者一个颜色时，只需要增加一个类就可以了。真香。

bridge 桥梁（接）模式

将抽象部分与它的实现部分分离，使它们都可以独立地变化。

把这绕口的东西看清楚

将抽象部分与它的实现部分分离，使他们都可以独立地变化。这句话我不知道别人能不能读的懂，就我而言，刚看到这句话实在是没有搞清楚在表达什么，我猜想其中的原因，一个是因为设计模式是搞建筑的人提出来了，另一个原因是老外写的软件设计模式。翻译成中文为了达到统一的标准，所以很多知识变得晦涩难懂。

这里在顺带提一下所谓的统一的标准，就像开放平台的接口一样。他为了有更好的扩展性，定义了统一的对外接口，以后无论哪方想要对接，都需要适应我的标准，而不是给每个人都定制化一个接口。所以知识的传播也一样，要以一定的官方标准来定义和传播，不然可能传着传着就出现了歧义。这也就是复杂度守恒定律的根本，它本身其实真的并不复杂。以上个人见解，可以无视。