当一个类实现了一个后代接口时,为什么它不会自动算作实现了基接口? [英] When a class implements a descendant interface, why doesn't it automatically count as implementing the base interface?

查看:21
本文介绍了当一个类实现了一个后代接口时,为什么它不会自动算作实现了基接口?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

无法编译的原因是什么?

What's the reason this won't compile?

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

相反,这就是我让它工作的方式:

In contrast this is how I make it work:

InterfaceA := ImplementsAB as InterfaceB;

InterfaceA := InterfaceB;

我的意思是,如果 IInterfaceB 继承自 IInterfaceA 并且 TImplementsAB 实现 IInterfaceB,那么也实现 IInterfaceA 并且类型兼容是不合逻辑的吗?

I mean, if IInterfaceB inherits from IInterfaceA and TImplementsAB implements IInterfaceB, it wouldn't be logical to also implement IInterfaceA and be type compatible?

推荐答案

这是因为早期的 OLE/COM 有一个错误,Borland 决定与之兼容.这篇文章中提到了这一点:新的 Delphi 语言特性:Delphi for .NET 中接口的多重继承.解决方案是在类中明确列出所有祖先接口,如 Mikael 所写.

This so because early OLE/COM had a bug and Borland decided to be compatible with it. This is mentioned in this article: New Delphi language feature: Multiple inheritance for interfaces in Delphi for .NET. The solution is to list all ancestor interfaces explicitly in the class as Mikael wrote.

来自链接文章的一些引用:

Some quotes from the linked article:

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

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.

因此,COM 永远不会在实现 IClassFactory2 和 IClassFactory 的任何 COM 服务器上请求 IClassFactory2.

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

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

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.

这篇关于当一个类实现了一个后代接口时,为什么它不会自动算作实现了基接口?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆