当一个类实现了后代接口时，为什么它不自动算作实现了基接口？

Question

这无法编译的原因是什么？

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 并保持类型兼容是不合逻辑的吗？

Answer 1

这是因为早期的 OLE/COM 有一个错误，Borland 决定与其兼容。本文提到了这一点：新的 Delphi 语言功能：Delphi for .NET 中接口的多重继承 。解决方案是在类中显式列出所有祖先接口，如 Mikael 所写。

链接文章中的一些引用：

问题出在 COM 本身。为了加载模块，COM 将加载 DLL，在应该从 DLL 导出的众所周知的入口点上 GetProcAddress，调用 DLL 函数来获取 IUnknown 接口，然后调用 IClassFactory 的 QueryInterface。问题是，当 Microsoft 添加对 IClassFactory2 的支持时，他们在查询 IClassFactory 的现有代码之后添加了 IClassFactory2 的 QueryInterface。仅当查询 IClassFactory 失败时才会请求 IClassFactory2。

因此，COM 永远不会在同时实现 IClassFactory2 和 IClassFactory 的任何 COM 服务器上请求 IClassFactory2。

这个 bug 在 COM 中存在很长时间了。微软表示，他们无法使用操作系统服务包修复 COM 加载程序，因为 Word 和 Excel（当时）都依赖于错误行为。无论它是否在最新版本的 COM 中得到修复，Borland 都必须提供某种方法来在可预见的将来在 Win32 Delphi 中保留这种行为。突然将所有祖先添加到以前不存在的实现类中很可能会破坏现有代码，这些代码无意中落入与 COM 加载程序相同的模式。

Answer 2

使其工作的另一种方法是将两个接口都包含在类声明中。

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

我想这就是编译器认识到 TImplementsAB 实现 IInterfaceA 和 IInterfaceB 所需要的。