如何让孩子爱上设计模式 ——10.桥接模式(Bridge Pattern)

如何让孩子爱上设计模式 ——10.桥接模式(Bridge Pattern)



我有故事,你有酒吗?这年头写个技术文不讲个故事都不行,行,我讲;

还有发现很多的技术博文都开始有喜欢往文中插入几个表情的趋势了,

但是你真的插的姿势对了吗?这种事情不是随便插的,来来来,给你

见识下如何在适当的场景插入适当的表情以让读者感觉到易可赛艇

本文以讲故事插表情为主,讲述桥接模式为辅,多图预警,

简书上排版可能有些问题,最佳排版可见:

https://www.zybuluo.com/coder-pig/note/643756

我就喜欢这样光明正大的开着我的托马斯小火车,污污污


场景引入

在之前的章节中,我们都知道小猪开家奶茶店,凭借着独特

的奶茶制作工艺,每天都吸引了一堆吃货在门口排队。每天基本

都是坐着收钱,但是喜欢折腾的小猪并不只满足于卖奶茶和小吃,

他一直在寻求着新的盈利点。一天没事,他打开了“丑团外卖”,

看着别人做餐饮的怎么玩,咦,有加奶茶店竟然做起了卖煲仔

饭的副业,打着“新品煲仔饭新鲜出炉,买饭送饮料”的广告口号,

再看下销量,还不赖,饭 + 饮料 + 小吃,能再从饭里面捞一笔,

但是做什么饭好呢?思前想后还是做技术水平最低的扒类,去市场

买好扒,买些酱料腌制下,然后丢铁板上一煎,然后配点饭或者

意粉,成本也就10来块,妥妥地卖30块一份,23333

嘿嘿,打算卖这几样东西:

  • 牛扒
  • 猪扒
  • 牛扒饭
  • 猪扒饭
  • 牛扒意粉
  • 猪扒意粉

接着按照套路来,我们撸下代码,不用Bridge模式的一般玩法:

先建立一个扒的父类:Steak.java

接着继承这个扒类编写牛扒猪扒子类

再接着继承猪扒和牛扒,写出四个子类

准备就开卖了,写一个餐馆类来卖扒:

输出结果:

可以,老铁,没毛病,就这样开始搞事情了~


问题初现

新品推出,肯定是搞吃扒送饮料的套路,由此吸引了一大波贪小便宜

的吃货,人多了,要求也多了,吃货反馈最多的问题是:

没有鸡扒,这不清真!

视顾客为上帝的小猪,肯定是急急脚把鸡扒加上:

然后调用下就好,又一次解决了吃货的需要,小猪感到很愉悦。

鸡扒是有了,然后吃货们又说想吃鱼扒,照葫芦画瓢又得

继承,写三个类,有些繁琐,小猪开始意识到可能有些问题

但是因为懒和拖拉,还是默默接受了没毛病这个设定,然后

沿用原先的套路把鱼扒也加上了。


问题又现

此时的小猪正悠闲的玩着王者农药,他似乎没有意思到逐渐

向他靠近的挑战。店员小B走了过来:

对小猪说: “老板,客人想要羊扒。”

小猪此时正在打团,因为被打断导致了团灭,有些不悦的说道:

“那就加上啊,按照之前的鸡扒鱼扒套路玩啊,你怎么那么蠢?”

小B一脸尴尬的说道:客人觉得味道太单一,有的想要加番茄汁,

有的想要加黑椒汁…,我不知道该怎么办”

小猪突然意识到事态的严重性了,这得继承N次,建多少个类啊!

需要一个人静静,然后把手机递给了小B,语气凝重的说到:

这把黄金上铂金的晋级赛,输了扣你半个月工资!

然后扬长而去,小B看了看战绩:0:20:5?站在原地一脸懵逼~

小猪一边走一边想,按照原有的套路,加上汁又得

加上N多的类,如果顾客又想加配菜呢,这是要GG啊,

这耦合度太高了,旧套路必须推翻,得想个新的套路!

走着走着来到一个没人的地方了,小猪左顾右盼确定

没人后,悄悄地把自己的手塞到裤裆中,反复翻动,似乎

在寻找着什么,然后掏出了不可描述的长18.4cm的…

欲望知后事如何请听下回分解

读者老爷:下回个毛线,快把你这破车飚完!

好的,上回说到,小猪从裤裆里掏出了18.4cm长不可描述的东西

这个到底是什么呢?为何小猪要找没人的角落才敢掏出来?

读者老爷:

此物看上去黑硬粗,离近一看才知道是:

《如何让孩子爱上设计模式》

色的封面,质书皮,体书名,长18.4cm * 宽13cm

不可描述是因为此书是编程界三十六道绝世功法中的

一本,一但被别人知道了,必然会引起杀身之祸,小猪

小猪虽然已经掌握了其中的二十三式中的前九式,但是

还是没有自保的能力,所以平日只能藏于裤裆之中,

在没人的地方才敢拿出来反复研读。

读者老爷:

话说回来,小猪翻开《如何让孩子爱上设计模式》快速翻阅

着能够解决当前问题的设计模式,当翻到桥接模式的时候,

一段文字映入小猪的眼帘:

在软件系统中,某些类型由于自身的逻辑,它具有两个或

多个维度的变化,那么如何应对这种“多维度的变化”?

如何利用面向对象的技术来使得该类型能够轻松的沿着

多个方向进行变化,而又不引入额外的复杂度?这就要使用Bridge模式。

多维维度变化?小猪不解,继续往下看,看到一句心法:

将抽象部分与实现部分分离,使得他们可以独立地进行变化!

把变化的因素都分离出来,让他独立变化,然后在程序运行时

动态地将抽象与实现部分组合起来。而多维桥接需要互相持有,

比如这里的扒类持有饭意粉,酱汁类持有扒类!如果再

加上配菜,就加多一个配菜类持有酱汁类

没错,就是这样,小猪此刻犹如醍醐灌顶,灵魂附体,立马

飞身赶回店中,是时候用桥接模式来好好秀一波了!


桥接模式初显威风

回到店里的小猪就是一顿疯狂的操作,把变化因素都抽取出来:

先抽配餐类:

然后是饭和意粉

再抽扒类

牛扒与猪扒

改良后的卖扒套路:

输出结果:

原先要的效果实现了,再加上鸡扒和羊扒又如何:

就是这么简单,什么鱼扒,狗扒随便来,唰唰唰就加上了,

小猪表示无所畏惧!


桥接模式再显神威

正当小猪沾沾自喜的时候,店员小B急冲冲地跑进来喊道:

“小猪老板,前几天要加酱汁的顾客又来闹事啦!啊!啊!啊!”

小猪很淡定的说到:“莫方莫方,带我出去看看,我自能解决!”

刚出店门,小猪就被眼前的景象所惊呆了:

三个跳舞的基佬:

小猪:,走开,我要打死这群基佬

店员小A和小B:

恢复了一下情绪后,小猪问到:“就是你们三个加酱汁是吧?”

跳舞的基佬:“是的,我们分别要黑椒汁,番茄汁和香草汁,今天

要是不给我们搞,我们就继续在这里跳舞,只要有空地,哪里都能跳尬舞!

小猪微微一笑,说到:“呵呵,原来是砸场子的,今日倒要给你们看看我的本事!”

跳舞的基佬:,心里念到:“难道此人还真有应付之法?”

小猪:,然后开始疯狂操作了起来!

变化的是酱汁,把他抽取出来,持有扒类

番茄汁,黑椒汁,还有香草汁

接着是调用部分

输出结果:

此时的输出结果,无不是狠狠的打了三个跳舞基佬的脸!碎碎念着想反驳,

小猪哥义正言辞到:”住口,三只断脊之犬,也敢在我店门前狺狺狂吠“!

跳舞基佬道:”你…猪哥村夫,你敢…,啊…“,三名基佬应声倒地不起。

小猪哥道:

围观群众无不拍手叫好,厉害厉害!

大获全胜的小猪大摇大摆地走回店里,而此时他却没发现,在暗处里

站着一个人

“原来《如何让孩子爱上设计模式》的功法在你手上,呵呵”,

随之露出一抹冷笑,然后消失在空气中…

小猪突然觉得背后一凉,回头一看却发现空无一人:

可能是心理作用吧,小猪安慰自己可能是心理作用吧。

躲在暗处的人到底是谁呢?为什么她会知道小猪持有18.4cm黑硬粗的

——《如何让孩子爱上设计模式》功法呢?是敌是友?是女是女?

小猪又会遇上怎样的危机呢?又会发生怎样的故事呢?

欲知后事如何,倾听下回分解…

======= 本章完 =======



PS:一不小心写得太(????)??嗨,时间也不早了,明儿要上班,

桥接模式的定义,UML类图,优缺点与使用场景明天再补!



本文代码

https://github.com/coder-pig/DesignPatternsExample/tree/master/9.Bridge%20Pattern


时间: 2024-10-13 18:49:50

如何让孩子爱上设计模式 ——10.桥接模式(Bridge Pattern)的相关文章

如何让孩子爱上设计模式 ——14.策略模式(Strategy Pattern)

如何让孩子爱上设计模式 --14.策略模式(Strategy Pattern) 描述性文字 本节讲解的是行为型设计模式中的第一个模式: 策略模式, 这个模式非常简单,也很好理解. 定义一系列的算法,把每个算法封装起来,并使得他们可以相互替换, 让算法独立于使用它的客户而变化. 一般用来替换if-else,个人感觉是面向过程与面向对象思想的 过渡,这里举个简易计算器的栗子,帮助理解~ 普通的if-else/switch计算器 普通的面向过程if-else简易计算器代码如下: 运行结果如下: 这里我

【设计模式】桥接模式 Bridge Pattern

开篇还是引用吕振宇老师的那篇经典的文章<设计模式随笔-蜡笔与毛笔的故事>.这个真是太经典了,没有比这个例子能更好的阐明桥接模式了,这里我就直接盗来用了. 现在市面上卖的蜡笔很多,各种型号,各种颜色种类繁多, 假如一盒蜡笔有24种颜色,那么它能涂抹出24种不同的颜色来,蜡笔型号是固定的,如果想画出各种线条那么就要购买不同型号的蜡笔,假如我们要涂抹出粗,中,细三种线条,那么我们就要买3盒粗,中,细型号的蜡笔才能满足需求,那么就是3盒*24色=72只蜡笔.假如使用毛笔来作画,我们需要准备3只粗,中,

二十四种设计模式:桥接模式(Bridge Pattern)

桥接模式(Bridge Pattern) 介绍将抽象部分与它的实现部分分离,使它们都可以独立地变化. 示例有一个Message实体类,对它的操作有Insert()和Get()方法,现在使这些操作的抽象部分和实现部分分离. MessageModel using System; using System.Collections.Generic; using System.Text; namespace Pattern.Bridge { /// <summary> /// Message实体类 //

设计模式-08桥接模式(Bridge Pattern)

1.模式动机 设想如果要绘制矩形.圆形.椭圆.正方形,我们至少需要4个形状类,但是如果绘制的图形需要具有不同的颜色,如红色.绿色.蓝色等,此时至少有如下两种设计方案: 第一种设计方案是为每一种形状都提供一套各种颜色的版本. 第二种设计方案是根据实际需要对形状和颜色进行组合 对于有两个变化维度(即两个变化的原因)的系统,采用方案二来进行设计系统中类的个数更少,且系统扩展更为方便.设计方案二即是桥接模式的应用.桥接模式将继承关系转换为关联关系,从而降低了类与类之间的耦合,减少了代码编写量. 当然,这

设计模式之桥接模式(Bridge)--结构模型

1.意图 将抽象部分与它的实现部分分离,使它们可以独立地变化. 2.适用性 你不希望在抽象和它的实现部分之间有一个固定的绑定关系. 类的抽象与它的实现都应该可以通过子类的方式加以扩展. 抽象部分与实现部分可以独立变化,而不会相互影响. 从多维度扩展应用程序. 3.结构 4.参与者 Abstraction: 定义抽象的接口:维护一个指向Implementor对象的引用. RefinedAbstraction: 扩充有Abstracttion定义的接口. Implementor: 定义实现类的接口,

设计模式-10外观模式(Facade Pattern)

1.模式动机 在现实生活中,常常存在办事较复杂的例子,如办房产证或注册一家公司,有时要同多个部门联系,这时要是有一个综合部门能解决一切手续问题就好了. 软件设计也是这样,当一个系统的功能越来越强,子系统会越来越多,客户对系统的访问也变得越来越复杂.这时如果系统内部发生改变,客户端也要跟着改变,这违背了"开闭原则",也违背了"迪米特法则(最少知道原则)",所以有必要为多个子系统提供一个统一的接口,从而降低系统的耦合度,这就是外观模式的目标. 2.模式定义 外观模式(F

【设计模式】—— 桥接模式Bridge

前言:[模式总览]——————————by xingoo 模式意图 这个模式使用的并不多,但是思想确实很普遍.就是要分离抽象部分与实现部分. 实现弱关联,即在运行时才产生依赖关系. 降低代码之间的耦合. 模式结构 Abstraction 抽象部分的基类,定义抽象部分的基础内容. RefinedAbstraction 抽象部分的扩充,用于对基类的内容补充,添加特定场景的业务操作. Implementor 实现部分的基类,定义实现部分的基本内容. ConcreteImplementor 具体的实现类

设计模式之桥接模式 Bridge

代码实现 public interface Brand { void sale(); } class Lenovo implements Brand{ @Override public void sale() { System.out.println("销售联想电脑"); } } class Dell implements Brand{ @Override public void sale() { System.out.println("销售戴尔电脑"); } }

8.桥接模式(Bridge Pattern)

using System; namespace ConsoleApplication6 { class Program { static void Main(string[] args) { // 创建一个遥控器 RemoteControl remoteControl = new ConcreteRemote(); // 长虹电视机 remoteControl.Implementor = new ChangHong(); remoteControl.On(); remoteControl.Set