yanyandt2，我懒得和你说了，
>>另外，你那个所谓的模式不是也开始别扭起来了吗？
我怎么不觉的，是你的幻觉吧。
当然你觉得别扭是正常的，因为只要是用Delphi谈模式你就觉得别扭。应该是你不会Delphi的缘故了。
你的问题“delphi的优势是模式？ ”本身就是错误的。模式是一种设计方法，怎么能
问“delphi的优势是模式？”这种问题！如果要这样问，那是不是还要问“C++的优势是模式？”，
“JAVA的优势是模式？”，这是不是太可笑了。
你觉得Delphi做模式别扭，那你就别扭吧，我没意见，你水平低我也没办法。如果有人要帮助你，
提高你的水平，使你不别扭，我也没意见。
不想再和你做无聊的争论，Delphi做模式好不好不是你说了算，你不会用就别用。
今天不断在思考Decorator模式，又有了新的领悟，至于用继承实现还是接口实现，都无所谓，不过
用接口显得高级些，比四人帮的C++例子还高级（yanyandt2认为这是是别扭，唉，无知是最可怕的，
因为C++没有接口，而Delphi有，所以又多一种方法实现该模式，可是yanyandt2却认为Delphi不能做
模式，可笑！）
Decorator模式的威力在于灵活，并且遵循了一个重要的原则，“优先使用类组合，而不是继承！”
这是它的强大威力所在。试想一下，如果大圣有72中变化，如果用继承，应该有72个子类，这没有问题，
用Decorator模式，则有72个Decorator，都差不多。好，接着的一个问题是，如果大圣变成“花儿”后，
直接变成“鸟儿”，改怎么办，哈，这下看到模式的威力了吧。如果用继承无能为力了，只能在“花儿”
子类上再派生一个“鸟儿”才能是“大圣－花儿－鸟儿”，可是前面已经有个“鸟儿”类型了
，更重要的是，
这种组合是无限的，继承在这里不是不好了，是彻底完蛋了。而用Decorator，则一切迎刃而解，只要
72个Decorator，剩下的就是组合这72个Decorator，你想如何组合就如何组合，不用生成任何新类。
//大圣化身——花儿、鱼儿、鸟儿——耍子去也
procedure TfmMain.Button7Click(Sender: TObject);
begin
TYuer.Create(TNiaoer.Create(THuaer.Create(THusun.Create))).Shuazi;
end;
这个太经典了，充分显示了Decorator模式的威力－－类的组合！试想，用继承谁能实现？
对Decorator的了解又深了一层，呵呵，不错。
一点心得，供大家参考，最近一直在研究模式，并一直在努力用模式重构以前的代码，初见成效，呵呵
感觉用（模式）来（重构）真的很爽！模式－重构 两本经典一起用，呵呵提高不少。
学以致用是最重要的，别象某些人，就只知道模式两个字，就在那里瞎吵吵。
