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和类型兼容是合乎逻辑的？
解决方法
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.