Счетчик ссылок интерфейса Delphi

Ответ 1

tl; dr Это все по дизайну - это просто изменение дизайна между XE2 и XE3.

XE3 и более поздние

Существует отличная разница между делегированием свойства интерфейса и делегированием свойства класса. В самом деле, документация вызывает эту разницу явно с разными разделами для двух вариантов делегирования.

Отличие от вашей перспективы заключается в следующем:

• Когда TObjectA реализует IInterfaceY, делегируя свойство класса type 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 is 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 имеет послужной список не изменяющегося поведения, если это абсолютно необходимо.

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

Ответ 2

Вы смешиваете указатели объектов и указатели интерфейса, которые всегда являются рецептом катастрофы. TObjectA не увеличивает счетчик ссылок на его внутренние объекты, чтобы гарантировать, что они остаются в живых на протяжении всего его жизненного цикла, а TestInterfaces() не увеличивает счетчик ссылок AA, чтобы обеспечить его сохранение по всему набору тестов. Указатели объектов НЕ участвуют в подсчете ссылок! Вы должны управлять им вручную, например:

procedure TObjectA.AfterConstruction;
begin
  inherited;
  FObjectB := TObjectB.Create;
  FObjectB._AddRef;
  FObjectC := TObjectC.Create;
  FObjectC._AddRef;
  FObjectC.FTest := 'Testing';
end;

procedure TObjectA.BeforeDestruction;
begin
  FObjectC._Release;
  FObjectB._Release;
  inherited;
end;

AA := TObjectA.Create;
AA._AddRef;

Излишне говорить, что ручной подсчет ссылок подрывает использование интерфейсов.

При работе с интерфейсами вам необходимо либо:

• Отключить подсчет ссылок полностью, чтобы избежать преждевременных разрушений. TComponent, например, делает именно это.

• ВСЕГДА используйте указатели интерфейса, НИКОГДА с указателями объектов. Это обеспечивает правильный подсчет ссылок по всем направлениям. Обычно это предпочтительное решение.