Decorator模式（孙悟空的七十二变） ( 积分: 100 )

Delphi 不支持多重继承，说明这个不适合模式设计。
JAVA 不支持多重继承，但这和模式设计没关系。
有道理，反正一句话，Delphi不适合模式设计，JAVA适合模式设计。
各位这下明白了，你们还要让yanyandt2怎么给你们说你们才明白呢？

对了，谁要是用锤子把蚊子杀死，我真服了他。
当然，你不能先把蚊子逮住后捆起来，放在案板上，然后一锤子砸死它，
那样我可不会佩服的。

对于Decorator模式，为何楼主要用接口，刚开始不太明白，后来由仔细研究了一下，
发现一个问题，由于四人帮用的是C++，所以没有直接的接口类型可用，而我用
Delphi实现Decorator模式时，用的和四人帮的C++的一样，也没有接口来实现。但是楼
主用了接口。我研究的结果是，用接口实现有一个好处，不用浪费内存。不用接口，直接
用继承的方式，那为该对象本身分配的内存似乎就被白白浪费了（当时学习这个模式的时候，
就觉得有浪费内存的嫌疑），而用接口就不会浪费内存。但是用接口显得更麻烦，更难以理解。
还不如就跟四人帮写的一样用继承来得直接，现在机器内存大得很，浪费百把十个字节没有问题，
呵呵。还有就是，如果用接口，要求被装饰的类必须是TInterFacedObject派生下来，似乎也
和Decorator模式的初衷不符合。因为我们要Decorator的类是现成，通常都是普通的class，
没法用接口呀。 不知理解是否正确，大家可以探讨一下。

来自：SS2000, 时间：2005-4-27 14:38:16, ID：3058944
Delphi 不支持多重继承，说明这个不适合模式设计。
JAVA 不支持多重继承，但这和模式设计没关系。
有道理，反正一句话，Delphi不适合模式设计，JAVA适合模式设计。
各位这下明白了，你们还要让yanyandt2怎么给你们说你们才明白呢？

我说过吗？你可真能编啊。。。。。。
另外，你那个所谓的模式不是也开始别扭起来了吗？
很明显，一群没事就拿delphi谈模式的，就是拿锤子杀蚊子的人，那还的
先把蚊子绑起来，然后放到案板上，在一锤子咂死，然后说：看，锤子杀
蚊子这不是也挺容易？

妈的，越看越想笑，也越觉的某人的无知和无耻：
根据你的话，提几个问题，请正面回答，答不来就别在这里现世：
A：“delphi的类的实现方式是在堆中，不是栈中，但又不能象java一样管理内存。”
言外之意，JAVA是基于栈而不是基于堆的，你在XX啊，什么是托管堆你懂吗？
JAVA什么时候基于栈的啊，你牛比？给我说说基于栈怎么来实现类的引用，请大虾正面回答！
B：“delphi中的接口仍然是对象。这点你去学习一下。”
还头一次听说Delphi的接口是对象，你说接口是对象，那么面向对象的三要素它应该有吧！那么接口中如何实现封装呢？别说是让你给吃了啊！！！请大虾正面回答！
C：“delphi本身的类库vcl所提供的类和方法对于设计模式来说还不足够”
我晕啊， 原来Delphi不适合设计模式的原因是它的类和方法不多啊！真怀疑你你懂不懂啊，解释你这句话！！
D：“模式不是离开接口就不能活了，在C++中，完全可以用类来代替接口，接口是面向
对象的一个进步。JAVA 不支持多重继承，但这和模式设计没关系。”
你懂不懂啊，“在C++中，完全可以用类来代替接口”，那么，你出题，我应招，咱不用Delphi中的借口，我用Delphi中的虚拟抽象类来给你实现接口，如何？无知的话就别性口雌黄啊！
E：“反正一句话，Delphi不适合模式设计，JAVA适合模式设计”，
听听，看看，有如下的味道啊：
婊子脱光了，在大街上一站，咋地， 老子就是卖的，你能把老子咋地
怕怕，惹不起，偶还躲不起吗？
靠

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的了解又深了一层，呵呵，不错。
一点心得，供大家参考，最近一直在研究模式，并一直在努力用模式重构以前的代码，初见成效，呵呵
感觉用（模式）来（重构）真的很爽！模式－重构 两本经典一起用，呵呵提高不少。
学以致用是最重要的，别象某些人，就只知道模式两个字，就在那里瞎吵吵。

喜欢模式的朋友,推荐一本好书<设计模式精解>,是通过从面向对象设计推导出模式来讲解的,我个人认为比<java与模式>好.

Delphi的优势是模式?
这个问题很有意思啊,模式只是一种设计思路和设计方法,
怎么能成为一种语言的优势呢,
既然是一种设计思路和方法,对于任何语言都是可用,
你只需要用面向对象的思想去考虑问题就行了,
很多人在谈Delphi的设计模式,
还举出了各种例子,而且实现这些模式并不比其它语言复杂,
这一点就充分证明了,设计模式是可以应用在Delphi中的
并能给开发和设计带来一些好处,
楼上也说,VCL类库中就使用了多种设计模式,
对于一种面向对象的语言来说,都是可以使用设计模式的,
你自己在编程的时候,如果对面向对象稍微有点了解和应用的话,
你就会不自觉的使用了某些设计模式,
很多事实已经证明了这个结论,
至于有些初学者置事实和证据而不顾,只知道坚持自己的意见,
丝毫听不进去别人的忠告,是大可不必理会的
有些知识,我们知道就行了,
没必要强迫别人接受

搬个凳子听课中... 长见识也...

just like delphi

A：“delphi的类的实现方式是在堆中，不是栈中，但又不能象java一样管理内存。”
言外之意，JAVA是基于栈而不是基于堆的，你在XX啊，什么是托管堆你懂吗？
JAVA什么时候基于栈的啊，你牛比？给我说说基于栈怎么来实现类的引用，请大虾正面回答！
这是我的言外之意吗？是你一厢情愿吧？我的意思是java也是基于堆的，但是提供了
管理内存的功能，而delphi没有。
B：“delphi中的接口仍然是对象。这点你去学习一下。”
还头一次听说Delphi的接口是对象，你说接口是对象，那么面向对象的三要素它应该有吧！那么接口中如何实现封装呢？别说是让你给吃了啊！！！请大虾正面回答！
不要怀疑这点，你自己找书看，看不明白就上网查，OK？
如果你们觉得爽我也没办法，因为有更爽的你们不用，我有啥招？
就好像楼上老兄写的那个模式，看着是很爽，可是实际中应用如何呢？几个类
如何要组合，肯定之间会有参数的传递，函数的调用。
就那破例子还爽呢，中看不中用，都不知道有啥可爽的。
delphi里谈模式的就这样，整天空谈。
另外，再拜托，你们都说vcl用了好多好多模式，举个例子？

SS2000:
如果大圣变成“花儿”后，
直接变成“鸟儿”，改怎么办，哈，这下看到模式的威力了吧。如果用继承无能为力了，只能在“花儿”
子类上再派生一个“鸟儿”才能是“大圣－花儿－鸟儿”，可是前面已经有个“鸟儿”类型了，更重要的是，
这种组合是无限的，继承在这里不是不好了，是彻底完蛋了。而用Decorator，则一切迎刃而解，只要
72个Decorator，剩下的就是组合这72个Decorator，你想如何组合就如何组合，不用生成任何新类。
小可初学，只是改写了阎宏的例子，没想到这一层。还请多多指教。

收到“老张” email 类图，另开一帖赠分！
http://www.delphibbs.com/delphibbs/dispq.asp?lid=3059857
欢迎富翁们多多指教。

yanyandt2,
冷静下来吧，你的观点有点偏激了。
如果，你把DELPHI当作高版本的VB来用，DELPHI确实也相当不错，你可能几乎用不到OO，
更可能用不到任何模式。
如果你用OO来分析问题，解决问题，必须要用到一些模式，因为模式就是为了规范OO设计，
写出更高效，优美的代码而生的。也就是说，不用OO，谈何模式。
设计模式相当于《数据结构》，是内功；而各种OO语言只是外功。

Delphi的接口实现了基于引用计数的实例内存管理,
字符串和动态数组也实现了自动内存管理的功能
Delphi的对象不允许在栈中创建,
但在堆中创建的对象,和C++中的内存管理差不多,都不能自动管理
如果想使用自动管理,可以考虑使用接口
关于接口是对象的说法,确实敢于打破常规,
但是,你看到他们之间的共同点时,
也不要忽略他们之间的差别
对象是类的实例,接口变量是一个接口的实例
接口必须被类实现,伴随着类的实例化,
接口也被实例化
在C++中,接口也是一个普通的类,但一般定义为抽象类
Delphi不支持多继承,但支持实现多个接口,
在使用接口变量时,也许你觉得和使用对象变量没有什么区别,
但是,要记住, 接口是对象之间的调用协议
关于VCL中涉及到的一些设计模式,简单的提一下,
Builder:
每个窗体根据.dfm被创建的过程,在创佳时都是一样的,
TReader
TWriter 是负责反向操作的
这是Delphi可视化得以实现的基础

FACTORY METHOD:
例子类:
TTreeView
function CreateNode: TTreeNode;
virtual;
function CreateNodes: TTreeNodes;
virtual;
TListView:
function CreateListItem: TListItem;
virtual;
function CreateListItems: TListItems;
virtual;
function CreateBlobStream(Field: TField;
Mode: TBlobStreamMode): TStream;
virtual;
TServerSocket 创建客户端Socket的方法
function GetClientSocket(Socket: TSocket): TServerClientWinSocket;
dynamic;
function GetServerThread(ClientSocket: TServerClientWinSocket): TServerClientThread;
dynamic;

PROTOTYPE:
function CloneConnection: TSQLConnection;
SINGLETON:
这个太多了,
TApplication,TScreen,TPrinter
Adapter:
TStreamAdapter
Bridge:
TPicture
FLYWEIGHT:
TField
Mediator:
TForm 的继承类通常充当这个角色
Memento:
TRecall
Observer:
DataControls
TDataSource
模板方法:
TDataSet
这几个只是早期delphi中的几个例子,
当时设计模式还没有人谈论,
当你看一些第三方的类库的时候,
会发现使用了更多的设计模式,
如: SQLDirect ICS FastReport 等
据说WebSnap中使用了大量的设计模式,
有兴趣的话,你可以研究一下
但事实上WebSnap并不好用,
大家更喜欢其它的Web开发类库,
设计的如此优秀的东西,却并不被大众接受
因为事件委托可以使问题简单化,
而不需要设计模式就可以解决很多设计模式中的问题,
需要的时候才使用,才是对待设计模式的正确态度

我还是那个观点，用delphi不适宜过多的考虑模式，
如果想逢东西就套模式，俺也没办法，随自己喜欢了。
lich 能不能留下联系方式啊？我有个东东想请教你一下：）

反正一句话，Delphi不适合模式设计，JAVA适合模式设计，。.net更好，C++就不用说了，
VB也凑合，PB也行，别说Delphi不适合模式设计，Builder C++也不适合，谁让它也用
VCL，并且和Delphi师出同门！靠，“我”是死猪，还怕你开水烫呀？！
哈哈！哈哈哈！

哈哈哈哈，真受不了这群喜欢yy的家伙，仅仅为了追求模式而模式
是啊，什么都可以使用模式！有人反对吗？没人吧！那就用去吧！
还有，现在TMD什么都喜欢跟风，什么流行就跟什么，盲从！
btw:阎宏那家伙的<<JAVA与设计模式>>,不撤上什么孙悟空还好，TMD，一扯上真TMD^!%@^#!#$

呵呵，没错，不能为了追求模式而模式
其实模式不是什么新东西，四人帮也说了，他们没有创造任何新东西，
他们只不过总结归纳了已有的东西而已。不过这就很了不起了。
我们其实经常再使用模式，只是不在意而已，并且由于没有标准，所以
用的也不好，还要自己探索。有了模式设计这本书后，前人的经验我们就
可以直接用了，省了多少事？在没有学习模式设计时，经常为了某个设计
方案而苦恼，现在有了模式，哈哈感觉一下子非常爽，很多混乱的思维一
下子就清楚了，原来有着么多好思路，根本不用我们再去研究费劲了。
我觉得模式好，是因为当我看到这本书时，一下子就有豁然开朗的感觉，以前
百思也没搞定的东西立刻就OK了！所以觉得模式非常好！
当时我一下买了十几本书，也不知道那本好，看了后就感觉有两本书很值
一本是《模式设计》，一本是《重构》，其他就一般了

哈哈，争论啊，有趣啊。
印象中《设计模式》中的大部分例子都已经有人用delphi实现了。如果你用
MM建模那有些模式的实现真实太简单了。
yanyandt2兄要冷静啊。Delphi不是只能用来RAD的。java .net 是好。但是也不是说Delphi就不行啊。java 。net的封装层次太高了。使得你很难接近系统底层。