更抽象的接口

thousandd

接口(Interface)这个词在早期开发中使用得很广泛。例如通常说的API，就是“应用程序接口(Applications Programming Interface)”；HCI，是“人机接口(Human-Computer Interface)。而pascal语言中，模块对外部系统的声明也称为接口，并有单独的关键字来标识它，甚至出现过单独的格式文件(.INT)来描述这些接口——在C语言中，与此相同的文件被称为头文件(.H)。
但这里要说的不是这些接口。

如果我们将对象系统理解为三个元素的复合体：
  数据：对象封装了数据体以及数据的存储逻辑；
  行为：对象向外表现了数据上可以进行的运算与运算逻辑；
  关系：对象系统设定了一些交互关系，例如观察者模式中的“观察”与“被观察”关系。
那么我们会发现这个对象系统所表达的含义又过于的确定了。也就是说，我们又回到了原来的话题上：数据系统与业务系统耦合度还是过高。

这个问题的根源还是抽象程度过低：我们确定了一个被运算的目标(对象)的结构与行为，其实在一定程度上也就限制了它的抽象性。而接口概念则更加符合我们对“自然系统”的定义：系统提供能力，我们使用系统的能力，而不是关注能力的来源与获取方法。
还是回到开始那个例子：我们需要一个计算系统来求和。但是我们为什么要关注这个计算系统是继承是怎样的一个基础类型呢？有了“基类”的概念后，我们就将在不同的子系统之间挖开了道道沟渠——我们无法让一个C++语言的对象用在Java中，也无法让一个继承自TManualCalc的对象与继承自TRobotCalc的对象互换——如果你一开始设计它们为不同的基类的话。

如果我们需要计算，那么我们其实只关心计算系统能否接受calc方法，方法的入口有一些计算元，然后返回计算结果即可。至于这个系统是人工在处理，还是计算机在处理，我们并不是真的那么需要关注。
接口(Interface)提出的观点就是：只暴露数据体的逻辑行为，而不暴露它的数据特性——这里用数据体而不是“对象”，是因为Interface并不关注实现者的数据结构特性(尽管具体的语言中，它是与对象或其它的数据类型相关的)。在有了接口的观念之后，我们会发现系统间的关系变得无比清晰明朗：用或者不用。
接口首次从系统或模块中剥离了“数据”的概念，进而把与数据有关的关系也清理了出去——例如引用(对象间的引用是面向对象体系的灾难之源)。因此，接口是一种更高层次的抽象。它是目标系统与计算机系统的功能特性的投影：如果二者的投影一致，则必然是一个能够互换或互证的系统。

接口的高度抽象带来了很多的附加价值。其中之一，就是体系的可描述性。例如某个部署在服务器上的Web Services，可能是一套由python开发极为复杂的系统，但对于外部的接口来说，可能只是一个Interface：