我有一些接口和对象.代码如下所示:
IInterfaceZ = interface(IInterface) ['{DA003999-ADA2-47ED-A1E0-2572A00B6D75}'] procedure DoSomething; end; IInterfaceY = interface(IInterface) ['{55BF8A92-FCE4-447D-B58B-26CD9B344EA7}'] procedure DoNothing; end; TObjectB = class(TInterfacedObject,IInterfaceZ) procedure DoSomething; end; TObjectC = class(TInterfacedObject,IInterfaceY) public FTest: string; procedure DoNothing; end; TObjectA = class(TInterfacedObject,IInterfaceZ,IInterfaceY) private FInterfaceB: IInterfaceZ; FObjectC: TObjectC; function GetBB: IInterfaceZ; public procedure AfterConstruction; override; procedure BeforeDestruction; override; property BB: IInterfaceZ read GetBB implements IInterfaceZ; property CC: TObjectC read FObjectC implements IInterfaceY; end; procedure TObjectB.DoSomething; begin Sleep(1000); end; procedure TObjectA.AfterConstruction; begin inherited; FInterfaceB := TObjectB.Create; FObjectC := TObjectC.Create; FObjectC.FTest := 'Testing'; end; procedure TObjectA.BeforeDestruction; begin FreeAndNil(FObjectC); FInterfaceB := nil; inherited; end; function TObjectA.GetBB: IInterfaceZ; begin Result := FInterfaceB; end; procedure TObjectC.DoNothing; begin ShowMessage(FTest); end;
现在,如果我访问像这样的各种实现,我得到以下结果:
procedure TestInterfaces; var AA: TObjectA; YY: IInterfaceY; ZZ: IInterfaceZ; NewYY: IInterfaceY; begin AA := TObjectA.Create; // Make sure that the Supports doesn't kill the object. // This line of code is necessary in XE2 but not in XE4 AA._AddRef; // This will add one to the refcount for AA despite the fact // that AA has delegated the implementation of IInterfaceY to // to FObjectC. Supports(AA,IInterfaceY,YY); YY.DoNothing; // This will add one to the refcount for FInterfaceB. // This is also allowing a supports from a delegated interface // to another delegated interface. Supports(YY,ZZ); ZZ.DoSomething; // This will fail because the underlying object is actually // the object referenced by FInterfaceB. Supports(ZZ,NewYY); NewYY.DoNothing; end;
第一个使用实现中的变量的Supports调用返回实际上是TObjectA的引用的YY.我的AA变量是引用计数.因为底层引用的计数对象是一个TObjectA,所以第二个支持(使用支持调用中的接口)工作并返回一个接口.底层对象实际上是一个TObjectB. FInterfaceB后面的内部对象是被引用计数的对象.这部分是有意义的,因为GetBB实际上是FInterfaceB.正如预期的那样,最后一次对Supports的调用为NewYY返回一个null,并且最终的调用失败.
我的问题是这个,是否引用了对TObjectA的第一个支持调用的设计?换句话说,当实现接口的属性返回一个对象而不是一个接口时,这是否意味着所有者对象将是引用计数的对象?我总是觉得实现也会导致内部委托对象被引用而不是主要对象.
声明如下:
property BB: IInterfaceZ read GetBB implements IInterfaceZ;
使用以上选项,FInterfaceB后面的内部对象是引用计数.
property CC: TObjectC read FObjectC implements IInterfaceY;
使用上面的第二个选项,TObjectA是被引用计数的,而不是委托对象FObjectC.
这是设计吗?
编辑
我在XE2中测试过,行为是不同的.第二个Supports语句对ZZ返回零. XE4中的调试器告诉我,YY是指(TObjectA为IInterfaceY).在XE2中,它告诉我它的一个(指针为IInterfaceY).此外,在XE2中,AA不是在第一个支持语句上被引用计数,而是内部的FObjectC是引用计数.
问题回答后的附加信息
有一个警告.您可以链接Interface版本,但不能链接对象版本.这意味着像这样的事情会奏效:
TObjectBase = class(TInterfacedObject,IMyInterface) … end; TObjectA = class(TInterfacedObject,IMyInterface) FMyInterfaceBase: IMyInterface; property MyDelegate: IMyInterface read GetMyInterface implements IMyInterface; end; function TObjectA.GetMyInterface: IMyInterface; begin result := FMyInterfaceBase; end; TObjectB = class(TInterfacedObject,IMyInterface) FMyInterfaceA: IMyInterface; function GetMyInterface2: IMyInterface; property MyDelegate2: IMyInterface read GetMyInterface2 implements IMyInterface; end; function TObjectB.GetMyInterface2: IMyInterface; begin result := FMyInterfaceA; end;
但是对象版本给出了一个编译器错误,这个说法是TObjectB不实现接口的方法.
TObjectBase = class(TInterfacedObject,IMyInterface) FMyObjectBase: TMyObjectBase; property MyDelegate: TMyObjectBase read FMyObjectBase implements IMyInterface; end; TObjectB = class(TInterfacedObject,IMyInterface) FMyObjectA: TObjectA; property MyDelegate2: TObjectA read FMyObjectA implements IMyInterface; end;
解决方法
XE3及更高版本
授予一个接口类型属性和委派给类类型属性有很大差异.事实上,documentation在两个代表团的不同部分中明确地提出了这个差异.
与您的观点不同之处如下:
>当TObjectA通过委派类类型属性CC实现IInterfaceY时,实现对象是TObjectA的实例.
>当TObjectA通过委托接口类型属性BB实现IInterfaceZ时,实现对象是实现FInterfaceB的对象.
一个关键的事情要实现的是,当你委派给一个类类型的属性时,被委派的类不需要实现任何接口.所以它不需要实现IInterface,所以不需要_AddRef和_Release方法.
要看到这一点,修改你的代码的TObjectC的定义是这样的:
TObjectC = class public procedure DoNothing; end;
您将看到该代码编译,运行,并且与您的版本完全相同.
实际上,这是理想的方式,如何声明一个接口被委派为类类型属性的类.这样做避免了混合接口和类类型变量的一生问题.
所以,我们来看看你对支持的三个电话:
Supports(AA,YY);
这里的实现对象是AA,所以AA的引用计数增加.
Supports(YY,ZZ);
这里的实现对象是TObjectB的实例,所以它的引用计数是递增的.
Supports(ZZ,NewYY);
这里,ZZ是由TObjectB实现的不实现IInterfaceY的接口.因此支持返回False,NewYY为零.
XE2及更早版本
XE2和XE3之间的设计变化与移动ARM编译器的引入相一致,并且有许多低级别的更改支持ARC.很明显,这些更改也适用于桌面编译器.
我可以发现的行为差异涉及将接口实现委派给类类型属性.具体来说,当有问题的类类型支持IInterface.在这种情况下,引用计数由内部对象执行.这与XE3不同,XE3具有由外部对象执行的引用计数.
请注意,对于不支持IInterface的类类型,引用计数由所有版本中的外部对象执行.这是有道理的,因为内部对象没有办法.
以下是我的示例代码来演示区别:
{$APPTYPE CONSOLE} uses SysUtils; type Intf1 = interface ['{56FF4B9A-6296-4366-AF82-9901A5287BDC}'] procedure Foo; end; Intf2 = interface ['{71B0431C-DB83-49F0-B084-0095C535AFC3}'] procedure Bar; end; TInnerClass1 = class(TObject,Intf1) function QueryInterface(const IID: TGUID; out Obj): HResult; stdcall; function _AddRef: Integer; stdcall; function _Release: Integer; stdcall; procedure Foo; end; TInnerClass2 = class procedure Bar; end; TOuterClass = class(TObject,Intf1,Intf2) private FInnerObj1: TInnerClass1; FInnerObj2: TInnerClass2; public constructor Create; function QueryInterface(const IID: TGUID; out Obj): HResult; stdcall; function _AddRef: Integer; stdcall; function _Release: Integer; stdcall; property InnerObj1: TInnerClass1 read FInnerObj1 implements Intf1; property InnerObj2: TInnerClass2 read FInnerObj2 implements Intf2; end; function TInnerClass1.QueryInterface(const IID: TGUID; out Obj): HResult; begin if GetInterface(IID,Obj) then Result := 0 else Result := E_NOINTERFACE; end; function TInnerClass1._AddRef: Integer; begin Writeln('TInnerClass1._AddRef'); Result := -1; end; function TInnerClass1._Release: Integer; begin Writeln('TInnerClass1._Release'); Result := -1; end; procedure TInnerClass1.Foo; begin Writeln('Foo'); end; procedure TInnerClass2.Bar; begin Writeln('Bar'); end; constructor TOuterClass.Create; begin inherited; FInnerObj1 := TInnerClass1.Create; end; function TOuterClass.QueryInterface(const IID: TGUID; out Obj): HResult; begin if GetInterface(IID,Obj) then Result := 0 else Result := E_NOINTERFACE; end; function TOuterClass._AddRef: Integer; begin Writeln('TOuterClass._AddRef'); Result := -1; end; function TOuterClass._Release: Integer; begin Writeln('TOuterClass._Release'); Result := -1; end; var OuterObj: TOuterClass; I1: Intf1; I2: Intf2; begin OuterObj := TOuterClass.Create; Supports(OuterObj,I1); Supports(OuterObj,Intf2,I2); I1.Foo; I2.Bar; I1 := nil; I2 := nil; Readln; end.
XE2的输出为:
TInnerClass1._AddRef TOuterClass._AddRef Foo Bar TInnerClass1._Release TOuterClass._Release
XE3的输出为:
TOuterClass._AddRef TOuterClass._AddRef Foo Bar TOuterClass._Release TOuterClass._Release
讨论
为什么设计改变了?我绝对不能回答这个决定.但XE3的行为对我来说更好.如果你声明一个类类型的变量,你可以期待它的生命周期被管理,就像其他的类类型的变量一样.也就是说,通过显式调用桌面编译器上的析构函数,以及ARC对移动编译器的调用.
另一方面,XE2的行为感觉不一致.为什么属性用于接口实现委托的事实会改变其生命周期的管理方式?
所以,我的直觉告诉我,这是一个设计缺陷,最好是在原来的接口实现授权中实现.设计缺陷导致了多年来的混乱和终身管理麻烦. ARC的介绍强制Embarcadero审查这个问题,他们改变了设计.我的信念是,ARC的引入需要设计更改,因为Embarcadero具有不改变行为的记录,除非绝对必要.
上面的段落显然是我的猜测,但这是我必须提供的最好的!