接口和抽象类的区别

3.1 相同点
都不能被直接实例化，都可以通过继承实现其抽象方法。

都是面向抽象编程的技术基础，实现了诸多的设计模式。

3.2 不同点
接口支持多继承；抽象类不能实现多继承。

接口只能定义抽象规则；抽象类既可以定义规则，还可能提供已实现的成员。

接口是一组行为规范；抽象类是一个不完全的类，着重族的概念。

接口可以用于支持回调；抽象类不能实现回调，因为继承不支持。

接口只包含方法、属性、索引器、事件的签名，但不能定义字段和包含实现的方法；抽象类可以定义字段、属性、包含有实现的方法。

接口可以作用于值类型和引用类型；抽象类只能作用于引用类型。

例如，Struct就可以继承接口，而不能继承类。

通过相同与不同的比较，我们只能说接口和抽象类，各有所长，但无优略。

在实际的编程实践中，我们要视具体情况来酌情量才，但是以下的经验和积累，或许能给大家一些启示，除了我的一些积累之外，很多都来源于经典，我相信经得起考验。

所以在规则与场合中，我们学习这些经典，最重要的是学以致用，当然我将以一家之言博大家之笑，看官请继续。

3.3 规则与场合
请记住，面向对象思想的一个最重要的原则就是：面向接口编程。

借助接口和抽象类，23个设计模式中的很多思想被巧妙的实现了，我认为其精髓简单说来就是：面向抽象编程。

抽象类应主要用于关系密切的对象，而接口最适合为不相关的类提供通用功能。

接口着重于CAN-DO关系类型，而抽象类则偏重于IS-A式的关系；
接口多定义对象的行为；抽象类多定义对象的属性；
接口定义可以使用public、protected、internal 和private修饰符，但是几乎所有的接口都定义为public，原因就不必多说了。

“接口不变”，是应该考虑的重要因素。

所以，在由接口增加扩展时，应该增加新的接口，而不能更改现有接口。

尽量将接口设计成功能单一的功能块，以.NET Framework为例，IDisposable、IDisposable、IComparable、IEquatable、IEnumerable等都只包含一个公共方法。

接口名称前面的大写字母“I”是一个约定，正如字段名以下划线开头一样，请坚持这些原则。

在接口中，所有的方法都默认为public。

如果预计会出现版本问题，可以创建“抽象类”。

例如，创建了狗（Dog）、鸡（Chicken）和鸭（Duck），那么应该考虑抽象出动物（Animal）来应对以后可能出现风马牛的事情。

而向接口中添加新成员则会强制要求修改所有派生类，并重新编译，所以版本式的问题最好以抽象类来实现。

从抽象类派生的非抽象类必须包括继承的所有抽象方法和抽象访问器的实实现。

对抽象类不能使用new关键字，也不能被密封，原因是抽象类不能被实例化。

在抽象方法声明中不能使用 static 或 virtual 修饰符。

******************************************************************************** *****************************************************************************
我想，对于各位使用面向对象编程语言的程序员来说，“接口”这个名词一定不陌生，但是不知各位有没有这样的疑惑：接口有什么用途？它和抽象类有什么区别？能不能用抽象类代替接口呢？而且，作为程序员，一定经常听到“面向接口编程”这个短语，那么它是什么意思？有什么思想内涵？和面向对象编程是什么关系？本文将一一解答这些疑问。

1.面向接口编程和面向对象编程是什么关系
首先，面向接口编程和面向对象编程并不是平级的，它并不是比面向对象编程更先进的一种独立的编程思想，而是附属于面向对象思想体系，属于其一部分。

或者说，它是面向对象编程体系中的思想精髓之一。

2.接口的本质
接口，在表面上是由几个没有主体代码的方法定义组成的集合体，有唯一的名称，可以被类或其他接口所实现（或者也可以说继承）。

它在形式上可能是如下的样子：
interface InterfaceName
{
void Method1();
void Method2(int para1);
void Method3(string para2,string para3);
}
那么，接口的本质是什么呢？或者说接口存在的意义是什么。

我认为可以从以下两个视角考虑：
1）接口是一组规则的集合，它规定了实现本接口的类或接口必须拥有的一组规则。

体现了自然界“如果你是……则必须能……”的理念。

例如，在自然界中，人都能吃饭，即“如果你是人，则必须能吃饭”。

那么模拟到计算机程序中，就应该有一个IPerson（习惯上，接口名由“I”开头）接口，并有一个方法叫Eat()，然后我们规定，每一个表示“人”的类，必须实现IPerson接口，这就模拟了自然界“如果你是人，则必须能吃饭”这条规则。

从这里，我想各位也能看到些许面向对象思想的东西。

面向对象思想的核心之一，就是模拟真实世界，把真实世界中的事物抽象成类，整个程序靠各个类的实例互相通信、互相协作完成系统功能，这非常符合真实世界的运行状况，也是面向对象思想的精髓。

2）接口是在一定粒度视图上同类事物的抽象表示。

注意这里我强调了在一定粒度视图上，因为“同类事物”这个概念是相对的，它因为粒度视图不同而不同。

例如，在我的眼里，我是一个人，和一头猪有本质区别，我可以接受我和我同学是同类这个说法，但绝不能接受我和一头猪是同类。

但是，如果在一个动物学家眼里，我和猪应该是同类，因为我们都是动物，他可以认为“人”和“猪”都实现了IAnimal这个接口，而他在研究动物行为时，不会把我和猪分开对待，而会从“动物”这个较大的粒度上研究，但他会认为我和一棵树有本质区别。

现在换了一个遗传学家，情况又不同了，因为生物都能遗传，所以在他眼里，我不仅和猪没区别，和一只蚊子、一个细菌、一颗树、一个蘑菇乃至一个SARS病毒都没什么区别，因为他会认为我们都实现了IDescendable这个接口（注：descend vi. 遗传），即我们都是可遗传的东西，他不会分别研究我们，而会将所有生物作为同类进行研究，在他眼里没有人和病毒之分，只有可遗传的物质和不可遗传的物质。

但至少，我和一块石头还是有区别的。

可不幸的事情发生了，某日，地球上出现了一位伟大的人，他叫列宁，他在熟读马克思、恩格斯的辩证唯物主义思想巨著后，颇有心得，于是他下了一个著名的定义：所谓物质，就是能被意识所反映的客观实在。

至此，我和一块石头、一丝空气、一条成语和传输手机信号的电磁场已经没什么区别了，因为在列宁的眼里，我们都是可以被意识所反映的客观实在。

如果列宁是一名程序员，他会这么说：所谓物质，就是所有同时实现了“IReflectabe”和“IEsse”两个接口的类所生成的实例。

（注：reflect v. 反映 esse n. 客观实在）
也许你会觉得我上面的例子像在瞎掰，但是，这正是接口得以存在的意义。

面向对象思想和核心之一叫做多态性，什么叫多态性？说白了就是在某个粒度视图层面上对同类事物不加区别的对待而统一处理。

而之所以敢这样做，就是因为有接口的存在。

像那个遗传学家，他明白所有生物都实现了IDescendable接口，那只要是生物，一定有Descend（）这个方法，于是他就可以统一研究，而不至于分别研究每一种生物而最终累死。

可能这里还不能给你一个关于接口本质和作用的直观印象。

那么在后文的例子和对几个设计模式的解析中，你将会更直观体验到接口的内涵。

3.面向接口编程综述
通过上文，我想大家对接口和接口的思想内涵有了一个了解，那么什么是面向接口编程呢？我个人的定义是：在系统分析和架构中，分清层次和依赖关系，每个层次不是直接向其上层提供服务（即不是直接实例化在上层中），而是通过定义一组接口，仅向上层暴露其接口功能，上层对于下层仅仅是接口依赖，而不依赖具体类。

这样做的好处是显而易见的，首先对系统灵活性大有好处。

当下层需要改变时，只要接口及接口功能不变，则上层不用做任何修改。

甚至可以在不改动上层代码时将下层整个替换掉，就像我们将一个WD的60G硬盘换成一个希捷的160G的硬盘，计算机其他地方不用做任何改动，而是把原硬盘拔下来、新硬盘插上就行了，因为计算机其他部分不依赖具体硬盘，而只依赖一个IDE接口，只要硬盘实现了这个接口，就可以替换上去。

从这里看，程序中的接口和现实中的接口极为相似，所以我一直认为，接口（interface）这个词用的真是神似！
使用接口的另一个好处就是不同部件或层次的开发人员可以并行开工，就像造硬盘的不用等造CPU的，也不用等造显示器的，只要接口一致，设计合理，完全可以并行进行开发，从而提高效率。

本篇文章先到这里。

最后我想再啰嗦一句：面向对象的精髓是模拟现实，这也可以说是我这篇文章的灵魂。

所以，多从现实中思考面向对象的东西，对提高系统分析设计能力大有脾益。

下篇文章，我将用一个实例来展示接口编程的基本方法。

而第三篇，我将解析经典设计模式中的一些面向接口编程思想，并解析一下.NET分层架构中的面向接口思想。

对本文的补充：
仔细看了各位的回复，非常高兴能和大家一起讨论技术问题。

感谢给出肯定的朋友，也要感谢提出意见和质疑的朋友，这促使我更深入思考一些东西，希望能借此进步。

在这里我想补充一些东西，以讨论一些回复中比较集中的问题。

1.关于“面向接口编程”中的“接口”与具体面向对象语言中“接口”两个词
看到有朋友提出“面向接口编程”中的“接口”二字应该比单纯编程语言中的interface范围更大。

我经过思考，觉得很有道理。

这里我写的确实不太合理。

我想，面向对象语言中的“接口”是指具体的一种代码结构，例如C#中用interface关键字定义的接口。

而“面向接口编程”中的“接口”可以说是一种从软件架构的角度、从一个更抽象的层面上指那种用于隐藏具体底层类和实现多态性的结构部件。

从这个意义上说，如果定义一个抽象类，并且目的是为了实现多态，那么我认为把这个抽象类也称为“接口”是合理的。

但是用抽象类实现多态合理不合理？在下面第二条讨论。

概括来说，我觉得两个“接口”的概念既相互区别又相互联系。

“面向接口编程”中的接口是一种思想层面的用于实现多态性、提高软件灵活性和可维护性的架构部件，而具体语言中的“接口”是将这种思想中的部件具体实施到代码里的手段。

2.关于抽象类与接口
看到回复中这是讨论的比较激烈的一个问题。

很抱歉我考虑不周没有在文章中讨论这个问题。

我个人对这个问题的理解如下：
如果单从具体代码来看，对这两个概念很容易模糊，甚至觉得接口就是多余的，因为单从具体功能来看，除多重继承外（C#，Java中），抽象类似乎完全能取代接口。

但是，难道接口的存在是为了实现多重继承？当然不是。

我认为，抽象类和接口的区别在于使用动机。

使用抽象类是为了代码的复用，而使用接口的动机是为了实现多态性。

所以，如果你在为某个地方该使用接口还是抽象类而犹豫不决时，那么可以想想你的动机是什么。

看到有朋友对IPerson这个接口的质疑，我个人的理解是，IPerson这个接口该不该定义，关键看具体应用中是怎么个情况。

如果我们的项目中有Women和Man，都继承Person，而且Women和Man绝大多数方法都相同，只有一个方法DoSomethingInWC（）不同（例子比较粗俗，各位见谅），那么当然定义一个AbstractPerson抽象类比较合理，因为它可以把其他所有方法都包含进去，子类只定义DoSomethingInWC（），大大减少了重复代码量。

但是，如果我们程序中的Women和Man两个类基本没有共同代码，而且有一个PersonHandle 类需要实例化他们，并且不希望知道他们是男是女，而只需把他们当作人看待，并实现多态，那么定义成接口就有必要了。

总而言之，接口与抽象类的区别主要在于使用的动机，而不在于其本身。

而一个东西该定义成抽象类还是接口，要根据具体环境的上下文决定。

再者，我认为接口和抽象类的另一个区别在于，抽象类和它的子类之间应该是一般和特殊的关系，而接口仅仅是它的子类应该实现的一组规则。

（当然，有时也可能存在一般与特殊的关系，但我们使用接口的目的不在这里）如，交通工具定义成抽象类，汽车、飞机、轮船定义成子类，是可以接受的，因为汽车、飞机、轮船都是一种特殊的交通工具。

再譬如Icomparable 接口，它只是说，实现这个接口的类必须要可以进行比较，这是一条规则。

如果Car这个类实现了Icomparable，只是说，我们的Car中有一个方法可以对两个Car的实例进行比较，可能是比哪辆车更贵，也可能比哪辆车更大，这都无所谓，但我们不能说“汽车是一种特殊的可以比较”，这在文法上都不通。

******************************************************************************** ****************************************************************************
简而言之：
1.首先，abstract class在Java语言中表示的是一种继承关系，一个类只能使用一次继承关系。

但是，一个类却可以实现多个interface。

2.其次，在abstract class的定义中，我们可以赋予方法的默认行为。

但是在interface 的定义中，方法却不能拥有默认行为，为了绕过这个限制，必须使用委托。

3.在abstract class方式中，可以有自己的数据成员，也可以有非abstarct的成员方法，而在interface方式的实现中，只能够有静态的不能被修改的数据成员（也就是必须是static final的，不过在interface中一般不定义数据成员），所有的成员方法都是abstract的.
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
以下来自《java与模式》
抽象类和接口
什么是接口：接口就是一些方法特征的集合------接口是对抽象的抽象。

什么是抽象类：抽象类对某具体类型的部分实现------抽象类是对具体的抽象。

方法特征包括：方法的名字、参数的数目、参数的类型。

不包括：返回类型、参数名字、和抛出的异常。

接口是类型转换的前提、是动态调用的保证。

实现某一接口就完成了类型的转换（多重继承）；动态调用只关心类型，不关心具体类。

--------------------------------------------------------------------------------------------------------------------------------------
java接口（抽象类）用来声明一个新的类型。

Java设计师应当主要使用接口和抽象类将软件单位与内部和外部耦合起来。

换言之，应当使用java接口和抽象类而不是具体类进行变量的类型声明、参数的类型声明、方法的返回类型声明、以及数据类型的转换等。

当然一个更好的做法是仅仅使用接口，而不是抽象类来做上面这些事情。

在理想的情况下，一个具体类应当只实现接口和抽象类中声明的方法，而不应当给出多余的方法！
接口和抽象类一般作为一个类型等级结构的起点。

接口比抽象类更为抽象所以优先使用接口声明抽象类型！
--------------------------------------------------------------------------------------------------------------------------------------
抽象类和接口
抽象类仅提供一个类的部分实现。

抽象类可以有实例变量、以及一个或多个构造函数。

抽象类可以同时又抽象方法和具体方法。

一个抽象类不会有实例，它的构造函数不能被客户端用来创建实例。

一个抽象类的构造函数可以被其子类调用，从而使一个抽象类的所有子类可以有一些共同的实现，而不同的子类可以在此基础上有不同的实现。

接口比抽象类更为抽象所以有线使用接口声明抽象类！
抽象类是用来继承的。

（具体类不是用来继承的，“只要有可能不要从具体类继承---scott meryes”）。

抽象类设计原则：
1，抽象类应当拥有尽可能多的代码！（公用方法）。

代码集中于抽象的方向。

2，抽象类应当拥有尽可能少的数据！（公共属性）。

数据集中于具体的方向。

继承复用的使用条件------- Peter Coad条件
1. 子类是超类的一个特殊种类而不是超类的一个角色！正确区分“Has-A”“Is-A”的关系。

2. 子类之间不应发生替换！？
3. 子类具有扩展超类的责任，而不是置换（Override）掉或注销（Nullify）掉的责任。

4. 只有在分类学角度上有意义时才可以使用继承，不要从具体类继承。

接口和抽象类的区别：
1. 抽象类可以提供某些方法的实现。

如果向抽象类中加入一个新的具体的方法，那么所有的子类一下子就得到了这个方法。

接口做不到这一点！（这也许是抽象类的唯一优点）。

2．因java的单根结构限制，只类只能实现一个抽象类类型，而接口类型这无此限制。

这使抽象类作为类型定义工具的效能落后于接口。

接口是定义混合类型（实现多从继承）的理想工具。

2。

从代码重构的角度上讲，将一个具体类从构成一个接口类型实现起来更容易。

-----------------------------------------------------------------------------------------------------------------------------------------------
另一篇网络通文！
抽象类与接口的区别
abstract class和interface是Java语言中对于抽象类定义进行支持的两种机制，正是由于这两种机制的存在，才赋予了Java强大的面向对象能力。

abstract class和interface 之间在对于抽象类定义的支持方面具有很大的相似性，甚至可以相互替换，因此很多开发者
在进行抽象类定义时对于abstract class和interface的选择显得比较随意。

其实，两者之间还是有很大的区别的，对于它们的选择甚至反映出对于问题领域本质的理解、对于设计意图的理解是否正确、合理。

本文将对它们之间的区别进行一番剖析，试图给开发者提供一个在二者之间进行选择的依据。

一、理解抽象类
abstract class和interface在Java语言中都是用来进行抽象类（本文中的抽象类并非从abstract class翻译而来，它表示的是一个抽象体，而abstract class为Java语言中用于定义抽象类的一种方法，请读者注意区分）定义的，那么什么是抽象类，使用抽象类能为我们带来什么好处呢？
在面向对象的概念中，我们知道所有的对象都是通过类来描绘的，但是反过来却不是这样。

并不是所有的类都是用来描绘对象的，如果一个类中没有包含足够的信息来描绘一个具体的对象，这样的类就是抽象类。

抽象类往往用来表征我们在对问题领域进行分析、设计中得出的抽象概念，是对一系列看上去不同，但是本质上相同的具体概念的抽象。

比如：如果我们进行一个图形编辑软件的开发，就会发现问题领域存在着圆、三角形这样一些具体概念，它们是不同的，但是它们又都属于形状这样一个概念，形状这个概念在问题领域是不存在的，它就是一个抽象概念。

正是因为抽象的概念在问题领域没有对应的具体概念，所以用以表征抽象概念的抽象类是不能够实例化的。

在面向对象领域，抽象类主要用来进行类型隐藏。

我们可以构造出一个固定的一组行为的抽象描述，但是这组行为却能够有任意个可能的具体实现方式。

这个抽象描述就是抽象类，而这一组任意个可能的具体实现则表现为所有可能的派生类。

模块可以操作一个抽象体。

由于模块依赖于一个固定的抽象体，因此它可以是不允许修改的；同时，通过从这个抽象体派生，也可扩展此模块的行为功能。

熟悉OCP的读者一定知道，为了能够实现面向对象设计的一个最核心的原则OCP(Open-Closed Principle)，抽象类是其中的关键所在。

二、从语法定义层面看abstract class和interface
在语法层面，Java语言对于abstract class和interface给出了不同的定义方式，下面以定义一个名为Demo的抽象类为例来说明这种不同。

使用abstract class的方式定义Demo 抽象类的方式如下：
abstract class Demo ｛
abstract void method1();
abstract void method2();
…
｝
使用interface的方式定义Demo抽象类的方式如下：
interface Demo {
void method1();
void method2();
…
}
在abstract class方式中，Demo可以有自己的数据成员，也可以有非abstarct的成员方法，而在interface方式的实现中，Demo只能够有静态的不能被修改的数据成员（也就是必须是static final的，不过在interface中一般不定义数据成员），所有的成员方法都是abstract 的。

从某种意义上说，interface是一种特殊形式的abstract class。

从编程的角度来看，abstract class和interface都可以用来实现"design by contract"的思想。

但是在具体的使用上面还是有一些区别的。

首先，abstract class在Java语言中表示的是一种继承关系，一个类只能使用一次继承关系。

但是，一个类却可以实现多个interface。

也许，这是Java语言的设计者在考虑Java 对于多重继承的支持方面的一种折中考虑吧。

其次，在abstract class的定义中，我们可以赋予方法的默认行为。

但是在interface的定义中，方法却不能拥有默认行为，为了绕过这个限制，必须使用委托，但是这会增加一些复杂性，有时会造成很大的麻烦。

在抽象类中不能定义默认行为还存在另一个比较严重的问题，那就是可能会造成维护上的麻烦。

因为如果后来想修改类的界面（一般通过abstract class或者interface来表示）以适
应新的情况（比如，添加新的方法或者给已用的方法中添加新的参数）时，就会非常的麻烦，可能要花费很多的时间（对于派生类很多的情况，尤为如此）。

但是如果界面是通过abstract class来实现的，那么可能就只需要修改定义在abstract class中的默认行为就可以了。

同样，如果不能在抽象类中定义默认行为，就会导致同样的方法实现出现在该抽象类的每一个派生类中，违反了"one rule，one place"原则，造成代码重复，同样不利于以后的维护。

因此，在abstract class和interface间进行选择时要非常的小心。

三、从设计理念层面看abstract class和interface
上面主要从语法定义和编程的角度论述了abstract class和interface的区别，这些层面的区别是比较低层次的、非本质的。

本文将从另一个层面：abstract class和interface所反映出的设计理念，来分析一下二者的区别。

作者认为，从这个层面进行分析才能理解二者概念的本质所在。

前面已经提到过，abstarct class在Java语言中体现了一种继承关系，要想使得继承关系合理，父类和派生类之间必须存在"is a"关系，即父类和派生类在概念本质上应该是相同的。

对于interface 来说则不然，并不要求interface的实现者和interface定义在概念本质上是一致的，仅仅是实现了interface定义的契约而已。

为了使论述便于理解，下面将通过一个简单的实例进行说明。

考虑这样一个例子，假设在我们的问题领域中有一个关于Door的抽象概念，该Door具有执行两个动作open和close，此时我们可以通过abstract class或者interface来定义一个表示该抽象概念的类型，定义方式分别如下所示：
使用abstract class方式定义Door：
abstract class Door {
abstract void open();
abstract void close()；
}
使用interface方式定义Door：
interface Door {
void open();
void close();
}
其他具体的Door类型可以extends使用abstract class方式定义的Door或者implements 使用interface方式定义的Door。

看起来好像使用abstract class和interface没有大的区别。

如果现在要求Door还要具有报警的功能。

我们该如何设计针对该例子的类结构呢（在本例中，主要是为了展示abstract class和interface反映在设计理念上的区别，其他方面无关的问题都做了简化或者忽略）下面将罗列出可能的解决方案，并从设计理念层面对这些不同的方案进行分析。

解决方案一：
简单的在Door的定义中增加一个alarm方法，如下：
abstract class Door {
abstract void open();
abstract void close()；
abstract void alarm();
}
或者。