Подсчет Ссылок На Интерфейс Delphi

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 совпадают с введением компилятора mobile 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 есть послужной список не меняющегося поведения, если это не абсолютно необходимо.

пунктах выше явно спекуляция с моей стороны, но это лучшее, что я могу предложить!