Delphi接口参考计数

在今天测试的时候,我遇到了一个奇怪的情况.

我有一些接口和对象.代码如下所示：

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;

所以如果你想开始链接代理,那么你需要坚持使用接口或者以另一种方式解决.

解决方法

tl; dr这是所有设计 – 只是设计在XE2和XE3之间变化.

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具有不改变行为的记录,除非绝对必要.

上面的段落显然是我的猜测,但这是我必须提供的最好的！

Delphi接口参考计数

解决方法

相关推荐