进行接口的介绍，必须介绍一下程序语言发展的历史才行，鲁迅先生说过“治学先治史”，明白了程序语言发展的前世今生，才能知道为什么这么多语言为什么会这样，为什么么会那样？
计算机出现以后，科学家相继开发了多种语言，从smalltalk，Pascal，Basic，C语言，C++，java,.net等等，这些语言的发展步伐，可以看作是从面向过程向面向对象发展的一段历史。很多面向对象的书在介绍自己的历史的时候，都会给读者介绍这一段历史，并鼓吹OO编程是多么多么的优异。问题是，很多刚开始学程序的人根本不知道为什么要有这个转变，他们也很难理解OO语言中的虚函数，接口等概念到底为了什么而提出来。
我们在了解这一段历史以前，首先给大家介绍一个概念——“粒度”，什么是粒度？作者认为所谓粒度其实就是一个程序中使用代码单元的组合尺度，我们可以举一个例子，沙砾——砖块——房屋模板，我们设想去修建一座房子，其实有很多中修筑方法，如果你不闲麻烦，可以使用沙砾一点点地建筑，或者将沙砾烧制为砖块，用砖块来砌，甚至直接从工厂购买房屋的门，窗，墙组件来堆砌。这三种不同的方法代表了三种不同的组合尺度。沙砾是最小的单位，使用它搭建小的房子说不定还可以，但是毫无疑问，我们必须使用很多很多“沙砾”，不便于管理；砖块比沙砾聚合了一层，可以用来修建较大的房子了；房屋模板是最高的尺寸，使用它可以快速地搭建大规模的房屋。这三种尺度的区别和联系，与我们编写程序概念是有很大的相似之处的。
在早期学习Pascal，老师告诉我们这种面向过程语言的最基本的单元是过程和函数，它们是程序中的最小的组件。过程和函数可以实现最基本的代码重用，当我们把某些固定功能的代码使用过程和函数编写后，我们可以在程序中调用它们而不必在任何需要的地方都写上这样一段代码，这样的好处是显而易见的。在一些小型的程序里面，使用过程和函数是合适的，但是在大中型程序中，它们的弊端就显示出来，过程和函数的粒度太低了，如果我们一个系统，有10000个函数和过程，我们的程序员将不得不花费大量的时间去寻找和维护它们，10000个没有任何关系的函数和过程的管理难度是显而易见的，就好像10000个人的企业一样，如果没有部门和职务，这还不乱了套？！
面向对象语言的出现，就是为了解决这个问题，别听OO语言吹的天花乱坠，其实它出现就为一个理由——提高编程的粒度。面向对象语言的基本单位是类CLASS，类封装了很多数据成员和成员函数，过程，将最小组件的提高了一个等级，我们需要直接操作的不是过程和函数了，而是一个个更高层次上的类。我们把10000人分了很多部门，不同的部门负责不同的事宜，这样公司终于可以走上正轨了。
做成了类CLASS是否就万事大吉了呢？不一定，新的问题随之而来，也许我们有一个部门的人很多，可以做很多事情，如何在部门内部实现更好的管理呢？好比我们有一个类，它提供了很多种方法和属性，这些方法和属性其实可以分为一堆堆，为不同的功能服务，但是我们的类并没有做这个管理。在AO种，map对象拥有很多功能，比如管理图层，管理元素，管理选择集，进行地图显示，每种不同的功能都有好多方法和属性，现在这些属性和方法是杂乱无章，没有任何区别堆积在一个类里面的，当我们的程序员需要寻找一个方法的时候，不得不一个个去寻找，很不方便。
这个时候，接口interface出现了，C++的发明者第一次提出纯虚函数（其实就是接口）概念的时候，遭到了很多抵制，很多人都不明白接口的意义何在，我们用虚函数好好的，何必又出来个啥东西都没有的空架子？说它是类吧，又不能实现产生一个对象；说它是对象吧，又没有方法体来使用。接口出来干了一件好事，就是将类内部进行分类。对于map对象，我们可以做好几个接口，这些接口中定义不同功能的方法，函数和属性，map类实现这些接口，这样我们可以使用接口定义，实现对象。因此，所谓接口就是一系列相关方法与属性集合的定义。
Dim pGraphicsContainer as iGraphicsContainer
pGraphicsContainer=application.document.ActiveView.focusMap
pGraphicsContainer可以使用的属性和方法就只能是它定义的那部分了，而不能使用管理元素等的接口定义的方法和属性，那我们如何使用其它的功能呢？这就是所谓的QI(Query Interface)功能。从一个接口查询另一个接口。
Dim pGeoFeatureLayer as iGeofeatureLayer
pGeoFeatureLayer= pGraphicsContainer QI
好了，我们罗嗦了这么多，已经走进了COM的概念了，在正式介绍COM以前我们得最后罗嗦一点：计算机语言的发展历史，其实就是一部不断提高组件粒度的历史，不断提高代码重用的历史。以前我们使用过程和函数，后来我们使用类，现在我们使用接口，都是为了一个目的，让我们操作的组件在具体和抽象之间寻找一个平衡点。太具体了，如过程和函数，就没有了框架；太抽象，如类，就无法分别。
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/carlbiao/archive/2009/04/18/4088934.aspx