Justin写了一篇关于Decorator模式很好的文章来杯咖啡-装饰者模式(Decorator),详细地阐述了这一模式,图文并茂非常爽心悦目.
关于他举的".NET框架里的应用" ToolTip一例个人却有着不同的意见.意见的最大问题可能在于:对于Decorator的定义上.
体现了动态添加功能的就是Decorator吗?每个模式是不是应该有个本质的点,Decorator模式的本质又在哪里?
本着讨论使人进步的原则,我也来说说,欢迎大家一起来讨论,扔板砖.
大致摘录下Justin给我回复的几个观点.
1. ToolTip动态增加了Button的功能.装饰者模式的作用是动态扩展对象的职责，这个职责里除了对象原来就有的职责，应该也包括对象原来不存在的功能。
2.ToolTip和Button在IComponent上应该是接口统一的，这似乎有点象装饰者模式的类图结构
3.说某个实现是XX模式，不是因为这个实现跟XX模式的官方定义的类图完全一样，而是因为这个实现解决的问题跟XX模式要解决的问题完全一样，那么就可以说某个实现是XX模式
个人的理解如下:
1. 所有设计模式的实现手段无非就是 继承+组合,所以"ToolTip和Button在IComponent上应该是接口统一的"不能说明什么问题
2. ToolTip为Button动态添加了功能.弱弱地问,DP中只有Decorate可以动态添加功能吗?这应该是果,而非因
3"装饰者模式的重点在于相互装饰", 我要表达的是"可以互相装饰".如何A和B都是Decorator的话,A可以装饰B,B也可以装饰A,并且是动态的.所以为什么在GOF的UML图中有注释强调了 调用传入的Decorator同一Operation方法,不这样我想没法互相装饰,没法透明
public override void Operation()
{
supper.Operation();
this.AddOperation();
}
在我FCL(4):: ArrayList & List (2)一文,Henry Liang同学在回复里说SyncArrayList类里使用了Decorator.SyncArrayList是为ArrayList增加了同步的功能,但其没有体现动态,没体现互相装饰,所以我觉得这仍然不是Decorator模式.也许我的这一观点偏激,因为我觉得它没有体现了Decorator精髓的地方.
4.对于Justin的观点3,非常赞同.类图确实不需要完全一样.但个人认为每个模式都有一个本质点,本质点必须一样.
那么本质在哪里. 在于
public override void Operation()
{
supper.Operation();
this.AddOperation();
}
在于
abstract class Decorator : Component
{
protected Component ActualComponent;
}
只有透明只有可互相装饰,才能可以解决某种情况下子类数目呈爆炸性增长的问题.不至于出现那么多的Beverage子类,做简单重复的劳动.
5.退一步
Decorator为什么要继承自Component.这样做是为了透明,为让Decorator能够透明代替ConcreteComponet. 而Decorator为什么要在Operation()里扩充ConcreteComponent的目的也在于此,提供统一的接口.那么ToolTip继承自IComponent是出于这个目的吗?
归根结底:Decorator的意图为:动态地给一个对象添加一些额外的职责.
那么动态地给一个对象添加一些额外的职责是不是一定就是Decorator