很多人在接口定义中，喜欢使用派生的方式进行定义。但是我要说的是，接口不应该派生，而应该AS出来。
接口是一种契约，它和类不同。当接口从COM中诞生的时候，其具备的三个方法经常被人忽略：
IInterface = interface [''] function QueryInterface(const IID: TGUID; out Obj): HResult; stdcall; function _AddRef: Integer; stdcall; function _Release: Integer; stdcall; end;看一个体系的设计，其实就是看它基本架构中提供了什么服务。TObject如此，IInterface也是如此。
观察这个架构，其中，包含两类服务：
第一、 引用计数服务。这也是非常著名的接口生存器自管理的实现过程。包括_AddRef和_Release两个方法。
第二、 接口查询服务。从一个接口查询另一个接口的方式。
第一个大家都很熟悉，也不是我们今天关心的。主要来说说第二个服务：接口查询服务。
如果稍不注意，你可以会产生一个疑问：就有一个接口，它要这个QueryInterface有什么用？我非常理解这种想法。其实这个想法的根源很可能来自TObject给我们的映像！
在接口的世界里，我们处理的可不是一个单一的接口！一个典型的应用就是同一个实体，同时实现多个接口！这和对象完全不一样。
还有一点：接口不关心实现！对于我们对象来说，除了申明公布的方法，还得复杂去实现。接口就不一样，只要附属在某个对象上就可以了。对于使用者来说，完全不需要考虑那个对象来实现的，更不需要那个语言来实现的！
基于查询接口，我们还应该发现一个道理。在业务接口设计中并不主张你派生！虽然很多语言中提供了派生机制。
对于一个业务实体。它体现出来的特性，在对象体系中，派生类是基于基类附加的信息。而在接口体系中，额外的信息，会以更准确的接口来体现。如下图：
相对于对象体系，接口体系认为，所有额外公布出来的方法是有意义的集合！这个集合必然有它自己存在的意义。事实上，接口体系认为，这个集合一定是一个新的接口。如下图：
类可以是一个多个接口的混合体。因为实体往往在不同的地方表现出不同的方面。但是接口必须是单一职责的。将一些没有被设计者认真思考归类的方法，简单附加到一个接口上而形成新的接口的做法，在接口体系中是不被推荐的。
如果派生接口，我们可能会出现这样的用法：
IB = interface(IA)
end; a: IA;b: IB; b := TB.Create;a := IA(b);b := IB(a);这段代码，本身可能没有问题，可是你要是细想一下，所谓强制转换，就是说你已经知道IA和IB是同一个对象实现的了！并且他们的指针是同一个地址。这就是说你在使用这类接口的同时，已经知道它的实现了。
如果：
TA = class(TInterfacedObject, IA)
end; TB = class(TInterfacedObject, IB)end;那么你还会发现，IA(b)得到的接口和b as IA得到的接口不是同一个接口啊。下面这段代码可以验证：
type
IA = interface [''] procedure A; end; IB = interface(IA) [''] procedure B; end; TA = class(TInterfacedObject, IA) procedure A; end; TB = class(TA, IB) procedure B; end; 
... procedure TB.B;begin end; ... procedure TA.A;begin end; procedure TForm1.Button1Click(Sender: TObject);var a: IA; b: IB;begin b := TB.Create; ShowMessage(IntToStr(Integer(b))); a := IA(b); ShowMessage(IntToStr(Integer(a))); a := b as IA; ShowMessage(IntToStr(Integer(a)));end;也就是说，所谓的接口类型转换的代码实际上是依赖于实现的！这一点在接口体系中也是强烈不推荐的。
回到最初的话题。架构体系决定或者体现其设计原则。我们在接口体系的设计中，应该避免使用派生关系。多关注那些集合的本质所在。
记住，接口是AS出来的。
查看本文来源
用户评论