接口就是暴露在外的、可见的、供交互的、相互约定的一个实体或逻辑界面。接口一个很重要的概念就是要统一化、标准化并保持稳定性（接口稳定，实现可变）。
接口泛指实体把自己提供给外界的一种抽象化物（可以为另一实体），用以由内部操作分离出外部沟通方法，使其能被内部修改而不影响外界其他实体与其交互的方式。
In computing, an interface is a shared boundary across which two or more separate components of a computer system exchange information. The exchange can be between software, computer hardware, peripheral devices, humans and combinations of these.
在计算机中，接口是计算机系统中两个独立的部件进行信息交换的共享边界。这种交换可以发生在计算机软、硬件，外部设备或进行操作的人之间，也可以是它们的结合。
计算机系统的硬件系统和软件系统都有一个很重要的概念，就是模块。由模块构建软、硬件系统是计算机科学的一个很重要的原则。如硬件系统的外设与主机、主板的通过总线和插槽与显卡、内存卡连接。软件系统也是如此，操作系统、程序通过控制台的命令提示符或图形用户界面与用户交互，程序内部通过函数接口（函数返回值、函数名、参数）、类接口（类方法提供返回值、方法名、参数）来进行交互。
硬件系统区分输入、处理、输出三类设备和相互之间的接口。程序也一样，不同模块之间要实现交互，不管是函数模块，还是对象模块或组件模块。在函数内部也是一样，可以区分输入、处理、输出三部分。输入、输出就是接口的部分，对输入的处理形成输出就是黑匣子的部分。函数库、类库的黑匣子由提供者实现，使用者只需关心函数库、类库中具体函数、类的接口就行了。
接口的分类通常从接口交互的主体去区分。从系统的角度分析，接口也分为内部接口与外部接口，如硬件主板与显卡之间的接口可以理解为内部接口，外设与主板的接口可以理解为外部接口。程序也是如此，程序与用户的界面接口可以理解为外部接口，程序内部的模块之间的接口，如函数之间、类对象之间的接口可以理解为内部接口。
1 硬件接口硬件组件间的接口叫硬件接口，如插头与插座、芯片卡与主板插槽。如USB接口便可以实现设备连接，且可以即插即用。
2 操作系统接口
操作系统既是计算机硬件和其他软件的接口，又是用户与计算机的接口。
操作系统与用户的交互有两个方式，也就是两种接口：命令行界面与图形用户界面。
软件是运行在操作系统这个平台之上的，操作系统提供软件运行的环境，软件提供具体应用，操作系统与软件两者必须通过接口交互。同时，同一源程序要运行到不同的平台，需要进行不同的编码。
硬件也是必须运行在不同的操作系统平台上，为不同的操作系统提供驱动程序，实现操作系统与硬件两者的无缝连接。
3 程序接口程序接口可以从内部接口与外部接口去理解。
外部接口可以理解为程序与用户之间的接口，也就是用户界面，如同操作系统一样，有命令行界面与图形用户界面两种方式。
内部接口也就是程序组成模块或类对象之间的接口，下面将从函数接口与类接口去阐述。
应用程序之间也可以实现数据交换（互相通讯），如共享硬盘上的一个文件、DDE（动态数据交换）、Windows消息WM_COPYDATA、标准的Sockets和WinSock等。两个程序的进程间通信方法，如：发送消息，共享内存；命名管道、匿名管道，socket。
4 函数接口函数通过函数签名（函数返回值类型、函数名、函数参数三个部分组成的函数头）提供接口。有时，全局变量也可以成为接口的一部分。
API（Application Programming Interface,应用程序编程接口）是一些预先定义的函数，目的是提供应用程序与开发人员基于某软件或硬件得以访问一组例程的能力，而又无需访问源码，或理解内部工作机制的细节。Windows API是一套用来控制Windows的各个部件的外观和行为的预先定义的Windows函数。为了对外提供统一的API 接口，
5 类接口面向过程语言的最基本的单元是过程和函数，它们是程序中的最小的组件。过程和函数可以实现最基本的代码重用，当我们把某些固定功能的代码使用过程和函数编写后，我们可以在程序中调用它们而不必在任何需要的地方都写上这样一段代码，这样的好处是显而易见的。在一些小型的程序里面，使用过程和函数是合适的，但是在大中型程序中，它们的弊端就显示出来，过程和函数的粒度太低了，如果我们一个系统，有10000个函数和过程，我们的程序员将不得不花费大量的时间去寻找和维护它们，10000个没有任何关系的函数和过程的管理难度是显而易见的，就好像10000个人的企业一样，如果没有部门和职务，这还不乱了套？
面向对象语言的出现，就是为了解决这个问题，别听OO语言吹的天花乱坠，其实它出现就为一个理由：提高编程的粒度。面向对象语言的基本单位是类 CLASS，类封装了很多数据成员和成员函数，类将最小组件的粒度提高了一个等级，我们需要直接操作的不是过程和函数了，而是一个个更高层次上的类。我们把10000人分了很多部门，不同的部门负责不同的事宜，这样公司终于可以走上正轨了。
做成了类CLASS是否就万事大吉了呢？不一定，新的问题随之而来，也许我们有一个部门的人很多，可以做很多事情，如何在部门内部实现更好的管理呢？好比我们有一个类，它提供了很多种方法和属性，这些方法和属性其实可以分为一堆堆，为不同的功能服务，但是我们的类并没有做这个管理。在AO中，map对象拥有很多功能，比如管理图层，管理元素，管理选择集，进行地图显示，每种不同的功能都有好多方法和属性，这些属性和方法是杂乱无章，没有任何区别堆积在一个类里面的，当我们的程序员需要寻找一个方法的时候，不得不一个个去寻找，很不方便。
这个时候，接口interface出现了，C 的发明者第一次提出纯虚函数（其实就是接口）概念的时候，遭到了很多抵制，很多人都不明白接口的意义何在，我们用虚函数好好的，何必又出来个啥东西都没有的空架子？说它是类吧，又不能实现产生一个对象；说它是对象吧，又没有方法体来使用。接口出来干了一件好事，就是将类内部进行分类。对于map对象，我们可以做好几个接口，这些接口中定义不同功能的方法，函数和属性，map类实现这些接口，这样我们可以使用接口定义，实现对象。因此，所谓接口就是一系列相关方法与属性集合的定义。
计算机语言的发展历史，其实就是一部不断提高组件粒度的历史，不断提高代码重用的历史。就如同生产一个产品，每个零件都要自己去生产和组装，那就太繁琐了。如果同一个产品构建成几个模块，模块之间有接口可以衔接，这样生产这个产品组装起来就很快捷，且有问题也便于排除。
以前我们使用过程和函数，后来我们使用类，我们使用接口，都是为了一个目的，让我们操作的组件在具体和抽象之间寻找一个平衡点。太具体了，如过程和函数，就没有了框架；太抽象，如类，就无法分别。
类通过其定义的成员方法定义的接口与程序交互，只要接口不变，类内部的数据成员和方法逻辑的改变不会影响到程序对类的使用，如一个栈类可以从使用普通数组改变为使用动态数组或链表，只要修改类内部的实现，而程序对类的使用不需做任务变更，因为接口并没有改变。
6 面向接口编程接口在项目就是一个业务逻辑，面向接口编程就是先把客户的业务提取出来，作为接口。业务具体实现通过该接口的实现类来完成。当客户需求变化时，只需编写该业务逻辑的新的实现类，通过更改配置文件(例如Spring框架)中该接口的实现类就可以完成需求，不需要改写现有代码，减少对系统的影响。 采用基于接口编程的项目，业务逻辑清晰，代码易懂，方便扩展，可维护性强。即使更换一批人员，新来的人依然可以快速上手。对于公司来说，意义更大。&oq=接口在项目就是一个业务逻辑，面向接口编程就是先把客户的业务提取出来，作为接口。业务具体实现通过该接口的实现类来完成。当客户需求变化时，只需编写该业务逻辑的新的实现类，通过更改配置文件(例如Spring框架)中该接口的实现类就可以完成需求，不需要改写现有代码，减少对系统的影响。 采用基于接口编程的项目，业务逻辑清晰，代码易懂，方便扩展，可维护性强。即使更换一批人员，新来的人依然可以快速上手。对于公司来说，意义更大。在一些大型项目或者大型公司里,都是由架构师编写出系统接口,具体的实现类交给了程序员编写。
一个接口可以从三方面去考察： 制定者（或者叫协调者），实现者（或者叫生产者），调用者（或者叫消费者）。 接口本质上就是由制定者来协调实现者和调用者之间的关系。 所以通常说的“面向接口编程”可以理解为： 只有实现者和调用者都遵循“面向接口编程”这个准则，制定者的协调目的才能达到。 一个老生常谈的例子就是JDBC。 优点： 接口和实现分离了，适于团队的协作开发。&oq=一个接口可以从三方面去考察： 制定者（或者叫协调者），实现者（或者叫生产者），调用者（或者叫消费者）。 接口本质上就是由制定者来协调实现者和调用者之间的关系。 所以通常说的“面向接口编程”可以理解为： 只有实现者和调用者都遵循“面向接口编程”这个准则，制定者的协调目的才能达到。 一个老生常谈的例子就是JDBC。 优点： 接口和实现分离了，适于团队的协作开发。
The interface of a software module A is deliberately defined separately from the implementation of that module. The latter contains the actual code of the procedures and methods described in the interface, as well as other "private" variables, procedures, etc. Another software module B, for example the client to A, that interacts with A is forced to do so only through the published interface. One practical advantage of this arrangement is that replacing the implementation of A by another implementation of the same interface should not cause B to fail—how A internally meets the requirements of the interface is not relevant to B, which is only concerned with the specifications of the interface.
In some object-oriented languages, especially those without full multiple inheritance, the term interface is used to define an abstract type that contains no data but defines behaviours as method signatures. A class having code and data for all the methods corresponding to that interface and declaring so is said to implement that interface. Furthermore, even in single-inheritance-languages, one can implement multiple interfaces, and hence can be of different types at the same time.
Usually a method defined in an interface contains no code and thus cannot itself be called; it must be implemented by non-abstract code to be run when it is invoked. An interface called "Stack" might define two methods: push() and pop(). It can be implemented in different ways, for example, FastStack and GenericStack—the first being fast, working with a data structure of fixed size, and the second using a data structure that can be resized, but at the cost of somewhat lower speed.
Though interfaces can contain many methods they may contain only one or even none at all. For example, the Java language defines the interface Readable that has the single read() method; various implementations are used for different purposes, including BufferedReader, FileReader, InputStreamReader, PipedReader, and StringReader. Marker interfaces like Serializable contain no methods at all and serve to provide run-time information to generic processing using Reflection.
The use of interfaces allows for a programming style called programming to the interface. The idea behind this approach is to base programming logic on the interfaces of the objects used, rather than on internal implementation details. Programming to the interface reduces dependency on implementation specifics and makes code more reusable.
－End－
,
