在Delphi中,如何检查IInterface引用是否实现派生但不明确支持的

IBase = Interface ['{82F1F81A-A408-448B-A194-DCED9A7E4FF7}']
End;

IDerived = Interface(IBase) ['{A0313EBE-C50D-4857-B324-8C0670C8252A}']
End;

TImplementation = Class(TInterfacedObject,IDerived)
End;

以下代码打印“坏！” –

Procedure Test;
Var
    A : IDerived;
Begin
    A := TImplementation.Create As IDerived;
    If Supports (A,IBase) Then
        WriteLn ('Good!')
    Else
        WriteLn ('Bad!');
End;

这有点恼人但可以理解.支持不能转换为IBase,因为IBase不在TImplementation支持的GUID列表中.可以通过将声明更改为 –

TImplementation = Class(TInterfacedObject,IDerived,IBase)

然而,即使没有这样做,我已经知道A实现了IBase,因为A是一个IDerived,IDerived是一个IBase.所以如果我不用支票我可以投A,一切都会好的 –

Procedure Test;
Var
    A : IDerived;
    B : IBase;
Begin
    A := TImplementation.Create As IDerived;
    B := IBase(A);
    //Can now successfully call any of B's methods
End;

但是,当我们开始将IBases放入通用容器 – 例如TInterfaceList中时,我们遇到了一个问题.它只能保留IInterfaces,所以我们必须做一些投射.

Procedure Test2;
Var
    A : IDerived;
    B : IBase;
    List : TInterfaceList;
Begin
    A := TImplementation.Create As IDerived;
    B := IBase(A);

    List := TInterfaceList.Create;
    List.Add(IInterface(B));
    Assert (Supports (List[0],IBase)); //This assertion fails
    IBase(List[0]).DoWhatever; //Assuming I declared DoWhatever in IBase,this works fine,but it is not type-safe

    List.Free;
End;

我非常希望有一些断言来捕获任何不匹配的类型 – 这种事情可以使用Is操作符的对象来完成,但这对于接口来说不起作用.由于种种原因,我不想明确地将IBase添加到支持的接口列表中.有没有办法我可以写TImplementation和断言这样一个方式,它将评估为true如果硬化IBase(List [0])是一件安全的事情？

编辑：

在其中一个答案中,我补充说,我不想将IBase添加到TImplementation实现的接口列表中的两个主要原因.

首先,实际上并不解决问题.如果,在Test2中,表达式：

Supports (List[0],IBase)

返回true,这并不意味着执行硬执行是安全的. QueryInterface可能会返回一个不同的指针来满足请求的接口.例如,如果TImplementation显式实现了IBase和IDerived(和IInterface),则断言将成功传递：

Assert (Supports (List[0],IBase)); //Passes,List[0] does implement IBase

但是想象一下,有人误将一个项目作为IInterface添加到列表中

List.Add(Item As IInterface);

该断言仍然通过 – 该项目仍然实现IBase,但是添加到列表中的引用仅仅是一个IInterface – 将其硬化到IBase不会产生任何明智的,所以断言是不够的,铸造是安全的.确保工作的唯一方法是使用演播或支持：

(List[0] As IBase).DoWhatever;

但这是一个令人沮丧的性能成本,因为它的目的是将代码添加到列表中的代码的责任,以确保它们是IBase类型 – 我们应该能够承担这一点(因此,如果这个假设是假).这个说法甚至不是必要的,除非有任何人改变某些类型,否则要抓住以后的错误.这个问题来自的原始代码对于性能也是非常关键的,所以性能成本很少(在运行时仍然只能捕获不匹配的类型,但是没有编译更快版本的可能性)是我宁愿避免的.

第二个原因是我希望能够比较引用的相等性,但是如果同一个实现对象由具有不同VMT偏移量的不同引用持有,则不能完成此操作.

编辑2：以示例展开上述编辑.

编辑3：注意：问题是我如何制定断言,以便硬判决是安全的,如果断言通过,而不是如何避免强硬.有一些方法可以不同地进行强硬步骤,或者完全避免这种情况,但是如果运行时性能成本,我就不能使用它们.我想要在断言中检查所有的成本,以便以后可以编译.

话虽如此,如果有人可以完全避免这个问题,没有性能成本,没有类型检查的危险将是巨大的！