【2013.1.27】设计模式C++ 实现——Decorator

// // // // // // // // //

///2013.1.27

// // // // // // // // //

还记得前些天流行这样一个网络文化：

给名人找亲戚。

比如说诸葛亮先生，

不完全统计，

其有以下几个兄弟:

诸葛暗，诸葛闪光，诸葛亮不亮……

诸葛先生的兄弟们同样也神通广大，

每一个都喜欢自比管仲、乐毅，

每一个都能未出茅庐而心中已三分天下，

每一个都能在兵临城下之际而于空城之上淡然弹琴，

每一个都能在冬天岿然不动地扇扇子，

……

除此之外，

每一个都拥有自己的特色:

例如诸葛暗先生在晚上出去可以冒充包大人。。。等

那么，

我们该如何实现这些兄弟呢？

很容易的想到让拥有基础本领的诸葛亮作为基类，

每一个兄弟都去继承他，

再分别添加上自己的独家本领。

如果只有几个的话，

这个方法是没有问题的。

但是如果发动网友寻找诸葛家族百年史的话，

找出来几百万个诸葛XXX,

也都要继承么？

诸葛亮要告诉每个兄弟自己的本领，

然后告诉他们你们也有这些本领(基类功能)。

不管诸葛亮会不会累死，

但等到每个人都知道的时候(程序编译完成，准备执行)，

估计上帝都看不到了。

这个时候，

躲在角落里的Decorator模式笑了。

该它出场了。

【核心】Decorator通过继承并聚合基类，并在构造器中将其实例化，从而在不改变原有功能的基础之上实现功能的扩展。

UML图：

Component是基类(诸葛亮先生)，

ConcreteComponent是其功能的实现(传入Decorator的构造器中)。

至于ConcreteDecoratorA与ConcreteDecoratorB则是对Decorator实现不同功能的扩展了(就像诸葛暗与诸葛闪光之间的关系)。

在一开始我对Decorator有这样一个困惑，

就是为什么不直接将Component基类组合在Decorator之中，

还要再加一个继承关系呢？

不是能够到达同样的效果的么？

后来我仔细想了一下，

忽然发现自己犯了一个很没智商的问题：

如果只用组合的话，

还是设计模式么？

除此之外，

在网上找到了一个更为确切的答案，能够解决这一困惑：

Decorator是能够忠实地调用原有接口的基础上，进行功能的扩展。

脱离了继承关系，

谁知道你这个装饰器中还有原来方法的调用？(除此之外还有Protected类型不能访问的因素)

其实Decorator模式也是与Proxy，Composite等模式有相像之处的。

具体的区别会在日后涉及到此等模式时再详述。

设计模式之间很多都是共同的，

但是告诉大家一个记忆的方法，

就是名称记忆。

每一个模式的结构，

必然是围绕着其名称而实现的。

比如说Decorator名字就是装饰器，

因此它的功能就是装饰。

装饰是什么？

是添加扩展，在不改变原有结构的基础上，

方便地实现各种功能(取决于传入的Component实例)的扩展。

这个设计模式被广泛的应用于各种平台的Widget(控件)设计之中。

比如说InputWidget,其子类有Number_InputWidget,Char_InputWidget等(泛指)。

Button,其子类有ImageButton,AnimationButton等。