在线时间:8:00-16:00
迪恩网络APP
随时随地掌握行业动态
扫描二维码
关注迪恩网络微信公众号
网上有篇文章《Delphi接口编程的两大陷阱》,里面提到接口的生存期管理的问题。但该文章里面提到的两个问题,其实都是对 Delphi 不理解导致的。
先说该篇文章中提到的第一个问题为什么是该文章作者不理解 DELPHI 导致他认为那是不可理解的陷阱。然后俺再来重点解释接口的生命周期管理。
一. 接口 - 对象。
假设有接口定义:
IMyTask = interface
procedure SayHello;
end;
然后有个类实现了该接口:
TMyClass = class(TComponent, IMyTask)
public
procedure SayHello;
end;
然后有个该类的对象实例:MyObj := TMyClass.Create(Application); 和一个接口变量定义 MyIntf: IMyTask;
这时候,按 DELPHI 的语法规则,当然可以这样做:
MyIntf := MyObj as IMyTask;
也可以不用 AS 这样写:MyIntf := MyObj;
其实还有很多其它写法。总之,这里是从 MyObj 对象实例,取得它实现的接口的指针!而不是做类型转换!
前面提到的那篇文章的作者却以为这样做是【类型转换】,因此他就试图通过类型转换来做:MyObj := MyIntf...这样做当然是不行的!因为他的理解错误,使得他认为那是个陷阱。
事实上,一个对象可以实现多个接口。比如 TComponent 肯定也实现了IInterfaceComponentReference 接口。因此,我们还可以:
AInft: IInterfaceComponentReference;
AIntf := MyObj as IInterfaceComponentReference;
注意到没,一个对象可以拥有多个接口,因此,获取的该对象的接口的指针,肯定不是指向该对象的。否则两个接口的指针就打架了!所以,这里不能直接做类型转换,把指针转为对象!
那么,当我们有一个接口,如何获得它所在的对象呢?TComponent 实现的 IInterfaceComponentReference 接口刚好就帮我们实现了这个:function GetComponent: TComponent;
因此,如果是继承自 TComponent 的对象,它肯定有实现 IInterfaceComponentReference接口。因此,上面的 MyIntf: IMyTask 这个接口就可以通过以下方式获得它的对象指针:
AObj : TComponent;
AObj := (MyIntf as IInterfaceComponentReference).GetComponent;
------------------------------------------------------------
二. 接口生存周期的管理:
在 Delphi 里面使用接口,一个实现某个接口的类,必须实现 IInterface 接口的三个方法。
IInterface = interface
['{00000000-0000-0000-C000-000000000046}']
function QueryInterface(const IID: TGUID; out Obj): HResult; stdcall;
function _AddRef: Integer; stdcall;
function _Release: Integer; stdcall;
end;
上述3个方法里面,_Release 方法就负责释放对象自己。
当然,我们自己写一个类的时候,不用自己去实现这三个方法,只要我们的类从 TInterfacedObject 继承。TInterfacedObject 类已经实现了上述三个方法。
继承自 TInterfacedObject 的类,其对象被创建后,要使用该对象的方法、属性,俺隆重建议你引用该对象的接口,而不是引用该对象的对象实例。因为 TInterfacedObject 类里面已经写好,当接口引用计数为 0 的时候,自动释放该对象本身。也就是说,你的程序里到处使用该对象的某个接口,只要你想释放该对象,则只需要将对该接口的引用设置为 nil,也就是只要没有任何变量引用到该接口,该接口对应的对象实例会自动被释放掉。这样一来,你就不会有内存泄漏的问题了!
但是.......但是.......但是来了,需要注意的事情来了!
如果,你的类,是从 TComponent 类继承下来的,而且实现了你自己写的某个接口..........
TComponent 类的对象实例的接口引用为 0 的时候,并不会释放对象实例自己!你必须自己去释放对象本身,调用对象的 Free 方法。
这还是比较简单的概念。麻烦的是,如果你的对象A,拥有另外一个对象B的接口引用,当对象A被释放的时候,A内部的接口引用自然变成 nil,则会导致对象B内部的引用计数减一。问题是,如果在这之前,对象B已经被 FREE 了,这时候就会出现 AV 错误。
因此,这时候,一定要注意释放顺序!
当你给某个 TForm 的子类比如 TForm2 增加一个你自己定义的接口的时候,这样的错误就容易出现了。
以下是俺对该使用场景做的总结,此总结经过俺自己写代码测试确认过:
1. 如果该 Form 是属于 Application 的,则程序退出时,该 FORM 比主FORM先被消灭;
2. 如果主 FORM 里面引用了该 FORM 实现的接口,则主 FORM 被消灭时,
delphi 内部会自动将该接口引用置为 nil,导致 nil 了一个对象已经不存在的接口,
导致 AV 错误。
3. 但是,如果运行期,用按钮释放该 FORM,然后再用按钮事件设置该接口为 nil,
也就是设置了一个对象不存在的接口为 nil,并不会导致 AV 错误;
4. 实现接口的 FORM,运行期如果只释放其接口,其对象实例不会被释放
(好像继承自 TComponent 的类都是这样的)
5. 再次测试,如果被创建的有接口的 Form 不属于 Application 而是其 Owner 是创建它的主 Form,
则不需要在主FORM被销毁之前,做任何释放它的接口的动作,也不会出现 AV 错误。
再次重复一下上面的说法:
因此,程序退出时,要在主 FORM 里面的 OnClose 里面主动释放接口。
这里可以不用释放 FForm,等程序真正关闭时由 Application 来自动释放这个 Form。
也就是说,在这个 Form 释放前,必须先释放它被引用的接口。
这段测试也说明,主FORM的 OnClose 比其它 Form 的被释放更早一步执行。
一个普通的 Delphi 程序在关闭程序的时候,大概的执行顺序:
关闭主 FORM - 主 FORM.OnClose -- 其它 FORM 逐个被销毁 -- 主 FORM 被销毁。
总结:一定要注意释放顺序。而释放顺序要遵循的原理,则是 TComponent 的子类,释放完接口,对象不会自动释放,必须主动释放对象;但对象被释放以后再释放引用它的接口(比如 MyIntf := nil; )则会因为释放接口会使得执行对象内部引用计数减一,而该对象又已经不存在,去执行一个不存在的对象内的代码,导致 AV 错误!
http://blog.sina.com.cn/s/blog_44fa172f0102wl1o.html |
2023-10-27
2022-08-15
2022-08-17
2022-09-23
2022-08-13
请发表评论