基于东北F4的设计模式情景剧——第一幕 装饰模式(Decorator Pattern)

时间:2022-01-16 17:47:34

第一场 难题未解

布景:铁岭,晴天,午后,风。在一幢还算气派的写字楼的三层外墙上,挂着一条红色横幅,上面用歪歪扭扭的毛笔字写着“东北F4软件外包工作室”。大风中,那早已褪色的条幅剧烈地抖动着,发出阵阵嘶吼。房间内,东北F4正在为大鹏科技股份有限公司开发一款“大侠”游戏。

刘能(坐在椅子上,扭头冲众人):好……好啦,搞……搞定!我创建了一个大侠虚基类,然后派生出了三峡和张凤霞两……两个实例,每个大侠有两个功能:攻击和隐……隐身。这是我画的那什么U……U什么图:

基于东北F4的设计模式情景剧——第一幕 装饰模式(Decorator Pattern)

刘能:还有,这是我写的代……代码:

 class DaXia   //虚基类
{
public:
DaXia() {};
virtual ~DaXia() {};
virtual void GongJi() = ;
virtual void YinShen() = ;
}; class SanXia :public DaXia //三峡版本
{
public:
SanXia() {};
virtual ~SanXia() {};
virtual void GongJi()
{
cout << "来自三峡的攻击!" << '\n';
}
virtual void YinShen()
{
cout << "三峡已隐身!" << '\n';
}
}; class ZhangFengXia :public DaXia //张凤霞版本
{
public:
ZhangFengXia() {};
virtual ~ZhangFengXia() {};
virtual void GongJi()
{
cout << "来自张凤霞的攻击!" << '\n';
}
virtual void YinShen()
{
cout << "张凤霞已隐身!" << '\n';
}
};

(众人围拢过来看)

宋小宝:那啥,刚才大鹏给我打电话了,说每个大侠除了攻击和隐身两个核心功能外,还可能会有一些小的辅助功能,比如在攻击之前先跳一下,或者在隐身之前先喊话。之所以说可能,是因为对特定的大侠而言,可能完全具备这些辅助功能,也可能只具备一部分,还可能一点都不具备。总之,就是不确定,你们看,这咋整?

赵四(一脸得意):有什么不好整的,太简单了,让我来!

(两分钟后……)

赵四(愈发得意,将一张纸拍在众人面前):看吧!简直完美!

基于东北F4的设计模式情景剧——第一幕 装饰模式(Decorator Pattern)

赵四(摇头晃屁股):我设计的新类聚合了DaXia类,每个新类实现自己的动作,而原有的动作复用所聚合的类的代码。由于聚合的是大侠类的基类DaXia,所以所有的具体大侠类都可以被新类聚合,即新类适用于每一个具体大侠类,这在一定程度上减少了新增类的数量。假设我们需要一个在攻击前跳跃的三峡,只要用TiaoDaXia类的实例聚合一个SanXia类的实例就可以了;再比如,假设我们需要一个在攻击前跳跃,在隐身前喊话的张凤霞,只要用一个TiaoShuoDaXia类的实例聚合一个ZhangFengXia类的实例就可以了。你们说,我的设计是不是很棒……

小沈阳(没等赵四说完,就一巴掌扇到他的左脸上):棒你个脑袋!你设计的是啥玩意!你设计的新张凤霞类根本就不是大侠类的子类,这在逻辑上本身就不合理!更重要的,你看看我客户端的接口,是这样式儿的:

void DaXiaDongZuo(DaXia *daxia)
{
daxia->GongJi();
daxia->YinShen();
}

看着没?你说你设计的破玩意,叫我怎么用?我得改代码,得改,知道不!要是明儿需求有了新的变化,照你那么设计,我还得改,还得改,知道不!(伸手指着赵四)你软件开发是体育老师教的啊!知道啥叫“开闭原则”不?面向扩展开放,面向修改关闭!

赵四(一手捂着脸,一手指着小沈阳,愤怒而胆怯):你干嘛打我!不好就不好吧,你凭什么打我!(作发狠状)小样,这事没完,没完,知道不!今天这事必须有个了结!有种你给我等着,你给我十分钟,十分钟后,我保证——保证给你一个满意的方案!

(十分钟后)

赵四(战战兢兢走到小沈阳面前,颤抖着把一张纸拍在桌子上,马上又往后跳了一大截):小样,看好了!这回你满意了吧!这回你服了吧!你说,服不服!

(众人谁都没有理会赵四,全凑过去看赵四的新方案)

基于东北F4的设计模式情景剧——第一幕 装饰模式(Decorator Pattern)

赵四(神气活现地):这回服了吧!我采用派生子类的方式,完美地解决了你刚才说的所有问题。怎么样,我是不是很机智……

刘能(还没等赵四说完,一巴掌扇在他的右脸上):机智你个脑袋!他的问题解决了,我的呢?现在需要一个既跳又说的张凤霞,我就得新派生一个类,接下来,只跳不说的一个,只说不跳的一个,这就是三个;三峡下边,又是三个,这就六个了。如果明天还有新的需求出现,我还不得累吐血了啊!你来编码,你试试!这么多类,你叫我怎么维护?再说,你这是最简单,也是最笨、最愚蠢的做法!你发现了吗,对于跳这个功能,大家都是一样的,而你的设计,却不得不每个类都写一遍!一点复用都没有!

赵四(哭丧着脸走向宋小宝):宝啊,他们都欺负我,你说,要扩展一个类的方法,不就是聚合和继承吗?可他们……呜……宝啊……(作拥抱状)

宋小宝(一把推开赵四,极其轻蔑地)瞧你那损色!净想些找抽的方法!该!

赵四(委屈地):没想到连你也欺负我!(不服地)你还说我呢,有本事你想一个好办法!

宋小宝(心虚地):我要是有……有办法,还轮得着你挨打吗?

小沈阳(不耐烦地):行了行了,到下班时间了,今天先这样吧。大家各回各家,各找各妈。回去都想想,看这事咋整。

众人(无奈地):好吧,也只有如此了。

(众人下,传来赵四的嘟囔声:你们都给我听好了,这事没完,我的打不会白挨,明儿,我一定叫你们服服帖帖的……)

第二场 赵四逆袭

布景:打了一夜麻将的宋小宝揉着惺忪的睡眼晃晃悠悠走进工作室,见其他三个人正围在一起说着什么……

宋小宝(疑惑地):咋地啦,啥事呀?

赵四(神气活现、摇头晃脑,提着一张纸走到宋小宝面前):宝啊,看着没?哥夜以继日、通宵达旦、彻夜未眠、左思右想、绞尽脑汁、搜肠刮肚,终于在黎明的曙光中想出了完美的解决方案!怎么样,服不服?

宋小宝(仰起头发出一阵魔性的笑声):哈哈哈哈哈哈……这一大早上班,就听到这么好笑的笑话,(转向赵四,轻蔑地)瞧你那损色!你要是把这事摆平了,我就请大伙吃饭……

刘能、小沈阳(挥拳作胜利状):耶!

宋小宝(瞬间蒙圈):不是……咋……咋地?(疑惑地望着刘能和小沈阳,指着赵四)他真想出来了?

刘能、小沈阳(冲宋小宝肯定地点头):这回是真的!
宋小宝(心虚而疑惑地):等……等会儿,让我好好看看。

(众人的目光又聚集到赵四的设计上)

基于东北F4的设计模式情景剧——第一幕 装饰模式(Decorator Pattern)

(好几分钟后)

宋小宝(疑惑地望着赵四):你这设计的什么玩意啊,跟天书似得!

赵四(撇嘴):瞧你那损色!这都看不懂!

宋小宝(厉声):别抢我台词!有本事,你给解释一下。

(赵四用期待的目光望向刘能和小沈阳)

刘能(假装没看见,催促道):行啦,赶紧说吧,宝儿都等不及了。

小沈阳:大家鼓掌!

(众人鼓掌)

赵四(故作姿态地清了清嗓子):嗯嗯!我们看,在我们设计的游戏中,攻击和隐身是主要的、核心的功能,而攻击前跳跃、隐身前喊话是依托核心功能而存在的、是对核心功能的扩展和补充。可以说,跳跃和喊话是对核心功能的一种装饰。

众人(点头):有道理!

赵四(大模大样地徘徊在众人中间):所以,我从大侠类派生出一个装饰大侠(ZhuangShiDaXia)类,专门处理经过装饰后的大侠的动作。

刘能(举手打断):等一下!这不是和昨天一样吗?还得写好多好多类。

赵四(伸出右手食指在众人面前摇晃,同时缓慢地摇头):No、No、No,非也非也。大家仔细看,我把每种装饰都作为ZhuangShiDaXia类的子类。例如,在我们的问题中,有跳跃和喊话两种装饰,于是我从ZhuangShiDaXia类派生出跳大侠(TiaoDaXia)和说大侠(ShuoDaXia)两个子类,我们不妨称之为具体装饰类。每个具体装饰类都只实现自己的装饰功能,而其它功能则采用daxia指向的对象的版本。以TiaoDaXia为例,在它的GongJi功能中,先调用自己的Tiao功能,而具体的GongJi功能和该装饰无关的核心功能,如YinShen功能,则调用daxia指向的对象的版本。

刘能(不解地):daxia又是个什么鬼?

赵四(神秘而庄重地):然后就是重点了。不知大家是否注意到,ZhuangShiDaXia类除了派生自DaXia类,还聚合了DaXia类,即ZhuangShiDaXia类中有一个DaXia*类型的指针daxia。再回过头来看,由于ZhuangShiDaXia类派生自DaXia类,所以,daxia可以指向上图中的所有类,包括ZhuangShiDaXia类的子类。

小沈阳(一脸迷惑):这很重要吗?

赵四(激动地):太重要了!以ZhuangShiDaXia类的子类TiaoDaXia类为例,很显然,它继承了ZhuangShiDaXia类的daxia指针,而这个指针,还可以指向ZhuangShiDaXia类的子类,比如ShuoDaXia类,而ShuoDaXia类的daxia指针又可以指向其它DaXia类的子类……这样,就可以实现类的“层次嵌套”,也可以理解为一种递归,于是,就可以实现功能的*组合和调用时的“委托”。换句话说,你想要什么样的大侠,就可以组合出什么样的大侠,简直是变化万千,无穷无尽!哎呀,不能再说了,再说下去,我都佩服死自己了,哈哈哈哈!

宋小宝(迷惑地):好像明白了,又好像不明白,能举个例子吗?

赵四(胸有成竹地):当然能啦,我已经写好了一个Demo,大家请上眼!

 #include<iostream>

 using namespace std;

 class DaXia   //抽象基类
{
public:
DaXia() {};
virtual ~DaXia()
{};
virtual void GongJi() = ;
virtual void YinShen() = ;
}; class SanXia :public DaXia //三峡类
{
public:
SanXia() {};
virtual ~SanXia()
{};
virtual void GongJi()
{
cout << "来自三峡的攻击!" << '\n';
}
virtual void YinShen()
{
cout << "三峡已隐身!" << '\n';
}
}; class ZhangFengXia :public DaXia //张凤霞类
{
public:
ZhangFengXia() {};
virtual ~ZhangFengXia()
{};
virtual void GongJi()
{
cout << "来自张凤霞的攻击!" << '\n';
}
virtual void YinShen()
{
cout << "张凤霞已隐身!" << '\n';
}
}; class ZhuangShiDaXia :public DaXia //装饰大侠类
{
protected:
DaXia *daxia; //聚合DaXia类的直接或间接子类
public:
ZhuangShiDaXia() {};
ZhuangShiDaXia(DaXia *dx)
:daxia(dx)
{}
virtual ~ZhuangShiDaXia()
{
delete daxia;
daxia = NULL;
}
virtual void GongJi() //由所聚合的类实现功能
{
daxia->GongJi();
}
virtual void YinShen()
{
daxia->YinShen();
}
}; class TiaoDaXia :public ZhuangShiDaXia //具有跳装饰的大侠类
{
protected:
virtual void Tiao() //实现跳装饰
{
cout << "跳一下" << '\n';
}
public:
TiaoDaXia() {};
TiaoDaXia(DaXia *dx)
:ZhuangShiDaXia(dx)
{}
virtual ~TiaoDaXia()
{}
virtual void GongJi()
{
Tiao();
daxia->GongJi(); //具体的攻击功能交由所聚合的类完成
} //YinShen功能完全采用基类版本,即daxia->YinShen(),还是交由所聚合的类完成
}; class ShuoDaXia :public ZhuangShiDaXia //具有说装饰的大侠
{
protected:
virtual void Shuo() //实现说装饰
{
cout << "你来找我呀?!" << '\n';
}
public:
ShuoDaXia() {};
ShuoDaXia(DaXia *dx)
:ZhuangShiDaXia(dx)
{}
virtual ~ShuoDaXia()
{}
virtual void YinShen()
{
Shuo();
daxia->YinShen(); //具体的隐身功能交由所聚合的类完成
} //GongJi功能完全采用基类版本,即daxia->GongJi(),还是交由所聚合的类完成
}; int main()
{
ZhangFengXia *zfx = new ZhangFengXia(); //张凤霞
ShuoDaXia *sdx = new ShuoDaXia(zfx); //将张凤霞“嵌入”到具有说装饰的大侠实例中,构造出具有说装饰的张凤霞
TiaoDaXia *tdx = new TiaoDaXia(sdx);//将具有说装饰的张凤霞“嵌入”到具有跳装饰的大侠实例中,使得最终的大侠具有跳装饰和说装饰
tdx->GongJi();//攻击
tdx->YinShen();//隐身
delete tdx;
tdx = NULL;
sdx = NULL;
zfx = NULL; return ;
}

赵四(洋洋得意地):来,走一波!(赵四运行了程序)

基于东北F4的设计模式情景剧——第一幕 装饰模式(Decorator Pattern)

赵四(自豪地):看到了吧,我们构造出的大侠具有了跳装饰和说装饰。

刘能(懵懂地):还是不太懂……

赵四(故作不耐烦):好吧,我就再启发你一下。(又拿出一张纸)

基于东北F4的设计模式情景剧——第一幕 装饰模式(Decorator Pattern)

赵四:如上图所示,ZhangFengXia实例嵌入到ShuoDaXia实例中(即ShuoDaXia的daxia成员指向ZhuangFengXia实例),ShuoDaXia实例嵌入到TiaoDaXia实例中。当执行tdx->GongJi()时,执行代码

virtual void GongJi()
{
Tiao();
daxia->GongJi(); //具体的攻击功能交由所聚合的类完成
}

即先调用Tiao(),输出“跳一下”,然后执行daxia指向的实例的GongJi()函数,而此时的daxia(即this->daxia)指向的是ShuoDaXia实例,而ShuoDaXia类中的GongJi()函数依然采用的是从它的基类ZhuangShiDaXia继承过来的GongJi()函数,即依然执行daxia->GongJi(),而此时的daxia指向ZhangFengXia实例,于是调用ZhangFengXia类的GongJi()函数,输出“来自张凤霞的攻击!”。

tdx->YinShen()的执行类似。先执行TiaoDaXia类的YinShen()函数,而该函数完全继承自基类ZhuangShiDaXia,于是执行

virtual void YinShen()
{
daxia->YinShen();
}

而此时daxia指向ShuoDaXia实例,于是调用ShuoDaXia实例的YinShen()函数,即

virtual void YinShen()
{
Shuo();
daxia->YinShen(); //具体的隐身功能交由所聚合的类完成
}

于是先调用Shuo(),输出“你来找我呀?!”,然后再调用daxia指向的实例的YinShen()函数,而此时的daxia指向ZhangFengXia实例,于是调用ZhangFengXia类的YinShen()函数,输出“张凤霞已隐身!”。

众人(恍然大悟):哦,明白了!
小沈阳(若有所思):也就是说,具体装饰类只具体实现自己的装饰部分,而其它的,都交由它所聚合的类完成。例如,对TiaoDaXia而言,它只实现具体的跳功能,并将其封装进自己版本的GongJi()函数中,而具体的攻击行为和不由它装饰的隐身行为,则统统采用它所聚合的类的版本。
宋小宝(抢着道):更为关键的是,如果被聚合者也同样含有daxia指针,即是ZhuangShiDaXia的子类的话,它还会聚合其它的类,直到被聚合者不含daxia指针,如SanXia类和ZhangFengXia类。对于赵四给出的Demo,可以抽象出这样的“类的嵌套模型”。(举起手中的一张纸)

基于东北F4的设计模式情景剧——第一幕 装饰模式(Decorator Pattern)

刘能:没……没错!(指着赵四画的UML类图)通过继承和聚合,DaXia类和ZhuangShiDaXia类构成一个环,于是就可以实现类的“递归嵌套”了,而“递归出口”就是不含daxia指针的类。
小沈阳:而这种“递归嵌套”的过程,就是功能组合的过程。分析赵四给出的Demo,不难看出,从代码的层面来看,嵌套,或者说功能组合是由内而外的,而调用是由外而内的。如果调用到的方法是具体装饰类自己的版本,则先执行相关的装饰功能,然后将核心功能交给“下一层”,这样“层层委托”,直到未经装饰的类。

刘能(激动地):我彻……彻底懂了,我还能举……举一反反……三呢,看,如果想要一个在攻击之前跳两次的大侠,这……这么写就可……可以了。(说着敲出如下代码)

ZhangFengXia *zfx = new ZhangFengXia();   //张凤霞
TiaoDaXia *tdx1 = new TiaoDaXia(zfx); //跳一下
TiaoDaXia *tdx = new TiaoDaXia(tdx1); //再跳一下

赵四(摸着刘能的头):孺子可教也!

刘能(扒拉开赵四的手):边去!别摸我头!

赵四(故作高深地):其实,还有更简洁的写法。(敲出如下代码)

TiaoDaXia *tdx = new TiaoDaXia(new TiaoDaXia(new ZhangFengXia()));  
赵四:这么写更加简洁,但不太好懂,所以一开始我是分开写的。

小沈阳(若有所思):你别说,赵四整的这个“装饰模式”,还挺好的。我们知道,当需要对一个类的功能进行扩展时,一般有聚合和继承两种方式,前者可以减少新增加的类的数量,但可能会带来与客户端接口不兼容的问题,需要修改客户端;后者虽然保持了接口的一致性,但在变化有多种组合时,子类数量激增。装饰模式同时采用继承和聚合,两者相辅相成、相生相克,既保持了各自的优点,又克服了对方的缺点,更重要的是,由于同时使用了继承和聚合,可以动态地实现类的层次嵌套和功能的*组合,非常的灵活。

刘能:没……没错!当我们需要对核心功能进行装饰,而这些装饰又有很多变化和组合的时候,采用装饰模式是极好的。而且,当增加新的变化时,完全不用修改当前的代码,只需要增加一个具体装饰类就可以。也就是说,我们可以很方便地、随时随地地扩展功能,简直了,还有谁?very good!

宋小宝(不屑地撇嘴):得了,消停会儿吧,又不是你发明的!

赵四(故作深沉地):任何事物都有两面性。拿装饰模式来说,刚才大家都说了它的优点,却忽略了它的不足。与单纯的继承相比,装饰模式减少了项目中类的数量,但在具体应用时,却增加了客户端创建的对象的数量。假设我们需要一个在攻击前跳一下,在隐身前喊话的张凤霞,如果采用继承的方法,我们会从ZhangFengXia类派生一个具有相应功能的NewZhangFengXia类,客户端只需要创建一个NewZhangFengXia类的实例就可以了;而如果采用装饰模式,正如大家在我写的Demo里看到的,由于我们要组合、拼凑出相应的大侠,所以需要创建ZhangFengXia类的实例、ShuoDaXia类的实例、TiaoDaXia类的实例,共计3个实例。如果我们的类很大很复杂,那么,创建类的实例是比较耗时的,这样会影响系统效率。另外,装饰模式中对象之间是层层嵌套的,这就使得最终组合出来的对象比较复杂,一个调用会引起由外而内的一连串调用,一旦出现问题,我们往往不知道问题具体出现在哪个环节,只能逐层排查,显然这是很麻烦的。再者,正如大家看到的,在装饰模式下,客户端构造大侠实例的代码的可读性比较差,对于一个不懂设计模式的人来说,是比较难看懂这些代码的。所以,总的来说,在一定程度上,装饰模式会降低项目的效率,增加项目的复杂度。

小沈阳:可以呀,赵四,没看出来啊!有两把刷子!

(响起深沉伤感的音乐)

赵四(缓慢而深沉地):谢谢!(泪眼朦胧地眺望着远方)记得那是2010年,家里拿钱让我上《非诚勿扰》。我刚一上场,24盏灯就呼啦全灭了。从此,我就开始了屡败屡战的相亲征途。直到第999次相亲失败,我总算醒悟了,就我这副尊容,去相亲,说白了就是浪费感情。万念俱灰之下,我拿相亲剩下的钱,买了一台二手电脑,从此踏上了程序员这条不归路。我不像你们,都是加里敦、地理赛这些名牌大学的高材生,我是半路出家。于是,我是时时受欺负、处处被鄙视,可是(使劲挥拳),我不甘心!虽然我还没有媳妇,但我也是个男人!我也有尊严!所以,我一定要用实力证明自己!于是,我千方百计、处心积虑、不择手段地学习!终于,皇天不负苦心人,我做到了!

小沈阳(揉着眼睛,呜咽着说):太感人了!四儿呀,对不起,以前是大哥不好,以后,大哥再也不欺负你了!

刘能(擤了把鼻涕):太……太励志了!四儿呀,对……对不起,以前是二……二哥不好,以后,二哥再也不鄙……鄙视你了!

(宋小宝悄悄向门口退去,却不小心碰倒了垃圾桶,于是被小沈阳和刘能发觉)

小沈阳、刘能(追着跑在前面的宋小宝):宋小宝,你给我站住!

(完)