delphi – 当一个类实现后代接口时,为什么它不会自动计算为实现

发布时间：2020-12-15 10:15:54 所属栏目：大数据来源：网络整理

导读：什么原因不能编译？ type IInterfaceA = interface ['{44F93616-0161-4912-9D63-3E8AA140CA0D}'] procedure DoA; end; IInterfaceB = interface(IInterfaceA) ['{80CB6D35-E12F-462A-AAA9-E7C0F6FE0982}'] procedure DoB; end; TImplementsAB = class(TSingl

什么原因不能编译？

type
  IInterfaceA = interface ['{44F93616-0161-4912-9D63-3E8AA140CA0D}']
    procedure DoA;
  end;

  IInterfaceB = interface(IInterfaceA) ['{80CB6D35-E12F-462A-AAA9-E7C0F6FE0982}']
    procedure DoB;
  end;

  TImplementsAB = class(TSingletonImplementation,IInterfaceB)
    procedure DoA;
    procedure DoB;
  end;

var
  ImplementsAB: TImplementsAB;
  InterfaceA: IInterfaceA;
  InterfaceB: IInterfaceB;
begin
  ImplementsAB := TImplementsAB.Create;
  InterfaceA := ImplementsAB; >> incompatible types
  ...
end

相比之下，这是我如何使其工作：

InterfaceA := ImplementsAB as InterfaceB;

要么

InterfaceA := InterfaceB;

我的意思是，如果IInterfaceB继承自IInterfaceA和TImplementsAB实现了IInterfaceB，那么也可以实现IInterfaceA和类型兼容是合乎逻辑的？

解决方法

这是因为早期的OLE / COM有一个bug，Borland决定与之兼容。这在本文中提到： New Delphi language feature: Multiple inheritance for interfaces in Delphi for .NET.解决方案是在Mikael写道中，在类中显式列出所有祖先接口。

链接文章中的一些引用：

The problem was in COM itself. To load a module,COM would load the DLL,GetProcAddress on a well-known entry point that was supposed to be exported from the DLL,call the DLL function to obtain an IUnknown interface,and then QueryInterface for IClassFactory. The problem was,when Microsoft added support for IClassFactory2,they added the QueryInterface for IClassFactory2 after the existing code that queried for IClassFactory. IClassFactory2 would only be requested if the query for IClassFactory failed.

Thus,COM would never request IClassFactory2 on any COM server that implemented both IClassFactory2 and IClassFactory.

This bug existed in COM for a long time. Microsoft said that they couldn’t fix the COM loader with an OS service pack because both Word and Excel (at the time) relied on the buggy behavior. Regardless of whether it’s fixed in the latest releases of COM or not,Borland has to provide some way to preserve this behavior in Win32 Delphi for the forseeable future. Suddenly adding all ancestors into an implementing class that weren’t there before is very likely to break existing code that unintentionally falls into the same pattern as the COM loader.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!