Delphi接口参考计数

Question

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

我有很多接口和对象.代码如下所示:

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, IInterfaceZ, ZZ);
  ZZ.DoSomething;

  // This will fail because the underlying object is actually
  // the object referenced by FInterfaceB.
  Supports(ZZ, IInterfaceY, NewYY);
  NewYY.DoNothing;
end;

第一个Supports调用,它使用implements中的变量,返回YY,它实际上是对TObjectA的引用.我的AA变量是参考计数.因为底层引用计数对象是TObjectA,所以第二个支持,它使用supports调用中的接口,工作并返回一个接口.底层对象实际上现在是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返回nil.XE4中的调试器告诉我YY指的是(TObjectA作为IInterfaceY).在XE2中,它告诉我它是一个(指针作为IInterfaceY).此外,在XE2中,AA不会在第一个支持声明中引用,但内部FObjectC是引用计数.

回答问题后的其他信息

有一点需要注意.您可以链接接口版本,但不能链接对象版本.这意味着这样的事情会起作用:

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)
  …
end;

TObjectA = 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;

因此,如果您想开始链接委托,那么您需要坚持使用接口或以其他方式解决问题.

Answer 1

tl; dr这完全是设计 - 只是设计在XE2和XE3之间变化.

XE3及更高版本

委托与接口类型属性和委托给类类型属性之间存在很大差异.实际上,文档明确地使用两个委托变体的不同部分来区分这种差异.

与您的观点不同如下:

• 当TObjectA工具IInterfaceY通过委托给类类型属性CC,执行对象是实例TObjectA.
• 当TObjectA工具IInterfaceZ通过委托给接口类型属性BB,执行对象是实现对象FInterfaceB.

在所有这一切中要实现的一个关键事项是,当您委托给类类型属性时,委派给它的类不需要实现任何接口.所以它不需要实现IInterface,因此不需要_AddRef和_Release方法.

要查看此内容,请修改代码的定义,TObjectC如下所示:

TObjectC = class
public
  procedure DoNothing;
end;

您将看到此代码的编译,运行和行为与您的版本完全相同.

实际上,理想情况下,您将如何声明将接口委派为类类型属性的类.这样做可以避免混合接口和类类型变量的生命周期问题.

那么,让我们来看看你的三个电话Supports:

Supports(AA, IInterfaceY, YY);

这里实现对象是AA,因此引用计数AA增加.

Supports(YY, IInterfaceZ, ZZ);

这里实现对象是实例,TObjectB因此其引用计数递增.

Supports(ZZ, IInterfaceY, NewYY);

这里,ZZ是由实例TObjectB未实现的接口实现的IInterfaceY.因此Supports返回False并且NewYY是nil.

XE2及更早版本

XE2和XE3之间的设计变化与移动ARM编译器的引入相吻合,并且有许多低级变化支持ARC.显然,其中一些更改也适用于桌面编译器.

我可以找到的行为差异涉及将接口实现委托给类类型属性.特别是当有问题的类型支持时IInterface.在该场景中,在XE2中,引用计数由内部对象执行.这与具有由外部对象执行的引用计数的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, Intf1, 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有不改变行为的记录.

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