呵呵,要用的时候,还是得用。 |
无聊的比较 语言所处的层次不一样,为什么要以己之长来比别人的短处呢? VCL的设计同时兼顾了效率和扩展性,那么有些东西是需要牺牲的,它也比不过JAVA那种“反正我就是慢,不在乎那些牺牲”的言论,语言各有特点,各有各的适用范围,要是都一样了,干脆只出一种语言好了。 .NET或JAVA里对象接口混用是建立在独立的垃圾回收机制上的,但VCL没有,不要告诉我,这一点就是VCL不如这两种语言的原因之一。 虽然楼主恨铁不成钢的心情是可以理解的,但很多理由都不够充分,甚至是狡辩,没有杀伤力,就好比拿白痴能生活自理和很多医生不是院长来比一样。 VCL是不断进步的,如果在将来,它可以放弃以前要兼顾的一些特性,就能够踢开很多限制,实现更多的特性。 |
如果非要深究,楼主还是跟李维老师探讨一下吧,我等小辈水平太有限了,不过别忘了把聊天记录贴上共享哦。 以上言论如有不妥,敬请不吝赐教 |
定义一个这样接可就可以解决你说的那个两问题 IObject = interface function GetObjectInstance: TObject; procedure ReleaseObjectInstance; end; 其实也没什么,DELPHI就是DELPHI,有她自己的风格,只是你还不了解。 |
真所谓有得必有失。世界并非完美,人也是,语言机制也一样。某一特性或许在你看来是累赘在别人看来就是完美。要用不同角度看问题,没有绝对的不好也没有决对的Perfect |
你要求的接口混用的情况出现,我觉得是你设计出了问题,不是接口没有设计好,就是对象没有设计好。 还有关于释放的问题你的看看TInterfacedObject类了,TInterfacedObject类中Destroy是不会把还在引用的对象释放的,只是抛出一个异常(当然你可以改变这一点),你如果要用接口就从这个类派生。 TObject是核心,他不会为一个特定的需求去设计什么,我觉得设计本应该如此。 |
用java和c++的思想来使用delphi/pascal, 那是人的问题,不是delphi的问题。 |
VCL就现在来说,本来也就不是什么多先进的东西了。 |
原文中说“对象指针和接口指针并不是同一个地址”,这句话没有交代明白,同一个对象实例,怎么可能不是同一个地址呢,这一点解释不通。 事实上,做个简单的实验,发现对象指针和指口指针肯定是同一个地址。新建一个工程,在Form上放一个Memo控件: type IFoo = interface procedure Execute; end; TFoo = class(TInterfacedObject, IFoo) procedure Execute; procedure MyMethod; end; procedure Test(AFoo: IFoo); begin AFoo.Execute; end; procedure TForm1.FormCreate(Sender: TObject); var intf: IFoo; obj: TFoo; begin obj := TFoo.Create; obj.Execute; intf := obj; intf.Execute; Test(obj); Test(intf); end; procedure TFoo.Execute; begin Form1.Memo1.Lines.Add(Format(''this=%d'', [Integer(Self)])); end; 结果当然是地址都相同。 这段代码还说明了从对象转换到接口是很轻松的事情,连AS都不用(上面Test过程要求一个接口,由于obj这个对象实例实现了该接口,所以直接传递就可以了)。 至于原文中所说的“如何从接口转换到对象”,首先想到的是为什么要把接口转换到对象?动机是什么?通常,编程是基于抽象,用接口的目的就是为了让上层不必了解底层细节,将派生类看生基类是很自然的做法,反过来把基类向下强制转换为派生类就很费解了。 如果非要这么做,当且仅当你知道intf实现就是TFoo时,你可以用一个强制类型转换: TFoo(intf).MyMethod; |