接口的生存期管理

 
依据我的常识(此处是编程常识,不是Delphi使用常识)来讲,我认为接口是不需要生存期管理的,因为接口根本不可能生成真正的对象。但是Delphi却又一次打击了我的常识(咦,为什么要说“又”呢?),它的接口是有生存期的,而且必须实现以下三个方法:

function QueryInterface(const IID: TGUID; out Obj): HResult; stdcall;
function _AddRef: Integer; stdcall;
function _Release: Integer; stdcall;

  每次都要实现这三个方法是比较麻烦的,而且更重要的是,我不知道Delphi什么时候用以及怎么用这三个方法?所以我也不知道怎么实现这三个方法。

  如果不想自己实现这三个方法,你可以使用TComponent。因为TComponent已经实现了这三个方法,所以可以从它继承,就不用实现这三个方法了。

  这样就可以放心使用了吗?答案是否定的。因为Delphi在你把接口变量置为nil时偷偷的(因为很出乎我的意料)调用了_Release。

function _IntfClear(var Dest: IInterface): Pointer;
var
P: Pointer;
begin
Result := @Dest;
if Dest <> nil then
begin
P := Pointer(Dest);
Pointer(Dest) := nil;
IInterface(P)._Release;
end;
end;

  而_Release时又做了什么呢?

function TComponent._Release: Integer;
begin
if FVCLComObject = nil then
Result := -1 // -1 indicates no reference counting is taking place
else
Result := IVCLComObject(FVCLComObject)._Release;
end;

  不是Com对象的话,就什么也没作。我们作的不是Com对象,是不是就没有任何问题了呢?答案依然是否定的,考虑如下情况:

OBJ2 := TC2.Create;
try
Intf1 := OBJ2;
Intf1.DO;
Finally
OBJ2.Free;
Intf1 := nil;
End;

  会怎么样呢?会出非法地址访问错误。为什么?上面说过把接口引用设为nil时,会调用_IntfClear,而_IntfClear又会调用对象的_Release,而这时这个对象已经释放了,自然就出非法地址访问错误啦。

  有人说多此一举吗,接口引用只是个地址,没必要手动设为nil。

OBJ2 := TC2.Create;

try

Intf1 := OBJ2;

Intf1.DO;

Finally

OBJ2.Free;

End;

  结果可能还会出你的意料,还是非法地址访问错误。为什么?因为Delphi编译器耍了个小聪明,它认为你忘记把这个地址引用置为nil了,所以你会自动给你加上,看来Delphi编译器聪明过头了J。

  怎么解决呢?

  方法1,先把接口引用置为nil,再释放对象。

Intf1 := nil;
OBJ2.Free;

  方法2,把接口引用强制转成指针类型再置为nil。

Pointer(Intf1) := nil;

  此时相当于直接把地址清零,不会调用_IntfClear。

  我倾向于使用第二种方法,这样你就不用考虑先释放谁的问题了。而且有些设计模式中你可能只持有接口引用,而且你也不知道引用的对象什么时候释放,此时就必须使用方法2。

  例如考虑Composite模式。

TComposite = class(TComponent, I1)
Private
interList: TXContainer;//一个容器类,存放“叶子”的接口引用。
Public
Procedure Add (AIntf: I1);
function DO: Boolean;
End;

  它应该释放它的“叶子”吗?显然不是,那“叶子”是不是一定会晚于这个“合成对象”对象释放呢?我想也不一定吧。如果强制这样规定的话,就失去很多的灵活性。所以我们肯定想这些接口引用置nil时,不会和原对象发生什么关系,以免对象被释放后出非法地址访问错误。考虑使用什么容器呢?array?TList?TInterfaceList?

  首先想到肯定是TInterfaceList了,因为我们是要容纳的就是接口。但是对他进行Free时,它会把它所有容纳的接口置为nil,这正是我们不想要的。或者我们可以在Free之前先把它存储的接口引用转为指针再置为nil。

for I := 0 to interList.Count -1 do
Pointer(interList.Items[i]) := nil;

  可惜的是,编译错误“[Error] XXXX.pas(XX): Left side cannot be assigned to”。

  然后我们试一下array。

interList: Array of I1;

  动态数组是不要释放的。好像很好用,但是编译器释放它时还是会对每个元素置为nil的,而且是作为接口,仍然有非法地址访问错误的可能。可以这样

for i := Low(arr) to High(arr) do
Pointer(arr[i]) := nil;

  但是这毕竟是违反编码习惯的,而且每次使用都要记得作,不记得作也可能不会马上出错,所以有可能成为隐患。

  最后,就是使用TList。不过TList中是指针,所以Add时必须这样

procedure XXX.Add(AIntf: I1)
Begin
 InterList.Add(Pointer(AIntf));
End;

  由于它本来就保存的是指针,所以释放时也不需要特殊处理。

  好像比较完美,但是还是有一个陷阱,如果你写了这样的代码会怎么样呢?

interList.Add(TC2.Create);

  或者

Obj2 := TC2.Create;
interList.Add(Obj2);

  错!因为保存的是纯粹的指针,所以转化为接口时,对象引用到接口引用的地址转换没有进行(它也不知道如何进行),所以调用接口声明的方法时就又是一个非法地址访问错误。只能这么写:

interList.Add(Pointer(I1(TC2.Create)));

  虽然有些麻烦,相比之下这已是最佳方案(我所知的)了。因为你如果你忘记转会在第一次调用时就出错,比较容易发现错误(相比于使用array)。
 
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值