接口是AS出来的

很多人在接口定义中，喜欢使用派生的方式进行定义。但是我要说的是，接口不应该派生，而应该AS出来。

接口是一种契约，它和类不同。当接口从COM中诞生的时候，其具备的三个方法经常被人忽略：

IInterface=interface
['{00000000-0000-0000-C000-000000000046}']
functionQueryInterface(constIID:TGUID;outObj):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
['{CDDE945F-BD5C-49B4-AF21-945460782C62}']
procedureA;
end;

IB=interface(IA)
['{BE689474-2621-4BB0-BB1B-F77E6D557560}']
procedureB;
end;

TA=class(TInterfacedObject,IA)
procedureA;
end;

TB=class(TA,IB)
procedureB;
end;


...{TB}

procedureTB.B;
begin

end;

...{TA}

procedureTA.A;
begin

end;

procedureTForm1.Button1Click(Sender:TObject);
var
a:IA;
b:IB;
begin
b:=TB.Create;

ShowMessage(IntToStr(Integer(b)));
a:=IA(b);
ShowMessage(IntToStr(Integer(a)));
a:=basIA;
ShowMessage(IntToStr(Integer(a)));
end;

也就是说，所谓的接口类型转换的代码实际上是依赖于实现的！这一点在接口体系中也是强烈不推荐的。

回到最初的话题。架构体系决定或者体现其设计原则。我们在接口体系的设计中，应该避免使用派生关系。多关注那些集合的本质所在。

记住，接口是AS出来的。