abstract class和interface有什么区别

选择将功能设计为接口还是抽象类（在 Visual Basic 中为 MustInherit 类）有时是一件困难的事。“抽象类”是一种不能实例化而必须从中继承的类。抽象类可以完全实现，但更常见的是部分实现或者根本不实现，从而封装继承类的通用功能。有关详细信息，请参阅抽象类。

相反，“接口”是完全抽象的成员集合，可以被看作是为操作定义合同。接口的实现完全留给开发者去做。

接口和抽象类对组件交互都很有用。如果一个方法要求一个参数形式的接口，则任何实现该接口的对象都可以用在该参数中。例如：

' Visual Basic
Public Sub Spin (ByVal widget As IWidget)

// C#
public void Spin (IWidget widget)
此方法可以接受任何将 IWidget 实现为小部件参数的对象，即使 IWidget 的实现可能相差很大。抽象类也允许这种多态性，但须注意以下几点：

类可能只是从一个基类继承，所以如果要使用抽象类为一组类提供多态性，这些类必须都是从那个类继承的。
抽象类还可能提供已实现的成员。因此，可以用抽象类确保特定数量的相同功能，但不能用接口这样做。
这里是一些建议，帮助您决定使用接口还是抽象类为组件提供多态性。

如果预计要创建组件的多个版本，则创建抽象类。抽象类提供简单易行的方法来控制组件版本。通过更新基类，所有继承类都随更改自动更新。另一方面，接口一旦创建就不能更改。如果需要接口的新版本，必须创建一个全新的接口。
如果创建的功能将在大范围的全异对象间使用，则使用接口。抽象类应主要用于关系密切的对象，而接口最适合为不相关的类提供通用功能。
如果要设计小而简练的功能块，则使用接口。如果要设计大的功能单元，则使用抽象类。
如果要在组件的所有实现间提供通用的已实现功能，则使用抽象类。抽象类允许部分实现类，而接口不包含任何成员的实现。

1. 引言

在我之前的一篇post《抽象类和接口的谁是谁非》中，和同事管伟的讨论，得到很多朋友的关注，因为是不成体系的论道，所以给大家了解造成不便，同时关于这个主题的系统性理论，我认为也有必要做以总结，因此才有了本篇的新鲜出炉。同时，我将把上贴中的问题顺便也在此做以交代。

2. 概念引入

●什么是接口？

接口是包含一组虚方法的抽象类型，其中每一种方法都有其名称、参数和返回值。接口方法不能包含任何实现，CLR允许接口可以包含事件、属性、索引器、静态方法、静态字段、静态构造函数以及常数。但是注意：C#中不能包含任何静态成员。一个类可以实现多个接口，当一个类继承某个接口时，它不仅要实现该接口定义的所有方法，还要实现该接口从其他接口中继承的所有方法。

定义方法为：

以下为引用的内容：
public interface System.IComparable
{
    int CompareTo(object o);
}
public class TestCls: IComparable
{
    public TestCls()
    {
    }

    private int _value;
    public int Value
    {
        get { return _value; }
        set { _value = value; }
    }

   public int CompareTo(object o)
    {

        //使用as模式进行转型判断
        TestCls aCls = o as TestCls;
        if (aCls != null)
        {

        //实现抽象方法
        return _value.CompareTo(aCls._value);
        }
    }
}

●什么是抽象类？

抽象类提供多个派生类共享基类的公共定义，它既可以提供抽象方法，也可以提供非抽象方法。抽象类不能实例化，必须通过继承由派生类实现其抽象方法，因此对抽象类不能使用new关键字，也不能被密封。如果派生类没有实现所有的抽象方法，则该派生类也必须声明为抽象类。另外，实现抽象方法由 overriding方法来实现。

定义方法为：

以下为引用的内容：
/// <summary>
/// 定义抽象类
/// </summary>
abstract public class Animal
{
    //定义静态字段
    static protected int _id;
    //定义属性
    public abstract static int Id
    {
        get;
        set;
    }

    //定义方法
    public abstract void Eat();

    //定义索引器
    public string this[int i]
    {
        get;
        set;
    }
}

/// <summary>
/// 实现抽象类
/// </summary>
public class Dog: Animal
{
    public static override int Id
    {
        get {return _id;}
        set {_id = value;}
    }

    public override void Eat()
    {
        Console.Write("Dog Eats.")
    }
}

 

3. 相同点和不同点

3.1 相同点

●都不能被直接实例化，都可以通过继承实现其抽象方法。
●都是面向抽象编程的技术基础，实现了诸多的设计模式。

3.2 不同点

●接口支持多继承；抽象类不能实现多继承。
●接口只能定义抽象规则；抽象类既可以定义规则，还可能提供已实现的成员。
●接口是一组行为规范；抽象类是一个不完全的类，着重族的概念。
●接口可以用于支持回调；抽象类不能实现回调，因为继承不支持。
●接口只包含方法、属性、索引器、事件的签名，但不能定义字段和包含实现的方法；抽象类可以定义字段、属性、包含有实现的方法。 
●接口可以作用于值类型和引用类型；抽象类只能作用于引用类型。例如，Struct就可以继承接口，而不能继承类。

通过相同与不同的比较，我们只能说接口和抽象类，各有所长，但无优略。在实际的编程实践中，我们要视具体情况来酌情量才，但是以下的经验和积累，或许能给大家一些启示，除了我的一些积累之外，很多都来源于经典，我相信经得起考验。所以在规则与场合中，我们学习这些经典，最重要的是学以致用，当然我将以一家之言博大家之笑，看官请继续。

3.3 规则与场合

1.请记住，面向对象思想的一个最重要的原则就是：面向接口编程。
2.借助接口和抽象类，23个设计模式中的很多思想被巧妙的实现了，我认为其精髓简单说来就是：面向抽象编程。
3.抽象类应主要用于关系密切的对象，而接口最适合为不相关的类提供通用功能。
4.接口着重于CAN-DO关系类型，而抽象类则偏重于IS-A式的关系；
5.接口多定义对象的行为；抽象类多定义对象的属性； 
6.接口定义可以使用public、protected、internal 和private修饰符，但是几乎所有的接口都定义为public，原因就不必多说了。
7.“接口不变”，是应该考虑的重要因素。所以，在由接口增加扩展时，应该增加新的接口，而不能更改现有接口。
8.尽量将接口设计成功能单一的功能块，以.NET Framework为例，IDisposable、IDisposable、IComparable、IEquatable、IEnumerable等都只包含一个公共方法。
9.接口名称前面的大写字母“I”是一个约定，正如字段名以下划线开头一样，请坚持这些原则。
10.在接口中，所有的方法都默认为public。 
11. 如果预计会出现版本问题，可以创建“抽象类”。例如，创建了狗（Dog）、鸡（Chicken）和鸭（Duck），那么应该考虑抽象出动物（Animal）来应对以后可能出现风马牛的事情。而向接口中添加新成员则会强制要求修改所有派生类，并重新编译，所以版本式的问题最好以抽象类来实现。

12.从抽象类派生的非抽象类必须包括继承的所有抽象方法和抽象访问器的实实现。
13.对抽象类不能使用new关键字，也不能被密封，原因是抽象类不能被实例化。
14.在抽象方法声明中不能使用 static 或 virtual 修饰符。

以上的规则，我就厚颜无耻的暂定为T14条吧，写的这么累，就当一时的奖赏吧。大家也可以互通有无，我将及时修订。

4. 经典示例

4.1 绝对经典

.NET Framework是学习的最好资源，有意识的研究FCL是每个.NET程序员的必修课，关于接口和抽象类在FCL中的使用，我有以下的建议：

1.FCL对集合类使用了基于接口的设计，所以请关注System.Collections中关于接口的设计实现；
2.FCL对数据流相关类使用了基于抽象类的设计，所以请关注System.IO.Stream类的抽象类设计机制。

 

4.2 别样小菜

下面的实例，因为是我的理解，因此给经典打上“相对”的记号，至于什么时候晋升为“绝对”，就看我在.NET追求的路上，是否能够一如既往的如此执着，因此我将把相对重构到绝对为止（呵呵）。本示例没有阐述抽象类和接口在设计模式中的应用，因为那将是另一篇有讨论价值的文本，本文着眼与概念和原则的把握，但是真正的应用来自于具体的需求规范。

设计结构如图所示：

 

1. 定义抽象类

以下为引用的内容：
public abstract class Animal
{
    protected string _name;
    //声明抽象属性
    public abstract string Name
    {
        get;
    }

    //声明抽象方法
    public abstract void Show();

    //实现一般方法
    public void MakeVoice()
    {
        Console.WriteLine("All animals can make voice!");
    }
}

2. 定义接口

以下为引用的内容：
public interface IAction
{
    //定义公共方法标签
    void Move();
}

3. 实现抽象类和接口

以下为引用的内容：
public class Duck : Animal, IAction
{
    public Duck(string name)
    {
        _name = name;
    }
    //重载抽象方法
    public override void Show()
    {
        Console.WriteLine(_name + " is showing for you.");
    }

    //重载抽象属性
    public override string Name
    {
        get { return _name;}
    }

    //实现接口方法
    public void Move()
    {
        Console.WriteLine("Duck also can swim.");
    }

}

public class Dog : Animal, IAction
{
    public Dog(string name)
    {
        _name = name;
    }

    public override void Show()
    {
        Console.WriteLine(_name + " is showing for you.");
    }

    public override string Name
    {
        get { return _name; }
    }

    public void Move()
    {
        Console.WriteLine(_name + " also can run.");
    }

}

 

4. 客户端实现

以下为引用的内容：

public class TestAnmial
{
    public static void Main(string [] args)
    {
        Animal duck = new Duck("Duck");
        duck.MakeVoice();
        duck.Show();

        Animal dog = new Dog("Dog");
        dog.MakeVoice();
        dog.Show();

        IAction dogAction = new Dog("A big dog");
        dogAction.Move();
    }
}

5. 他山之石

正所谓真理是大家看出来的，所以将园子里有创新性的观点潜列于此，一是感谢大家的共享，二是完善一家之言的不足，希望能够将领域形成知识，受用于我，受用于众。

●[url=]dunai[/url]认为：抽象类是提取具体类的公因式，而接口是为了将一些不相关的类“杂凑”成一个共同的群体。至于他们在各个语言中的句法，语言细节并不是我关心的重点。
●桦山涧的收藏也很不错。
●Artech认为：所代码共用和可扩展性考虑，尽量使用Abstract Class。当然接口在其他方面的优势，我认为也不可忽视。
●shenfx认为：当在差异较大的对象间寻求功能上的共性时，使用接口；当在共性较多的对象间寻求功能上的差异时，使用抽象基类。

最后，MSDN的建议是：

●如果预计要创建组件的多个版本，则创建抽象类。抽象类提供简单易行的方法来控制组件版本。通过更新基类，所有继承类都随更改自动更新。另一方面，接口一旦创建就不能更改。如果需要接口的新版本，必须创建一个全新的接口。
●如果创建的功能将在大范围的全异对象间使用，则使用接口。抽象类应主要用于关系密切的对象，而接口最适合为不相关的类提供通用功能。
●如果要设计小而简练的功能块，则使用接口。如果要设计大的功能单元，则使用抽象类。
●如果要在组件的所有实现间提供通用的已实现功能，则使用抽象类。抽象类允许部分实现类，而接口不包含任何成员的实现。

6. 结论

接口和抽象类，是论坛上、课堂间讨论最多的话题之一，之所以将这个老话题拿出来再议，是因为从我的体会来说，深刻的理解这两个面向对象的基本内容，对于盘活面向对象的抽象化编程思想至关重要。本文基本概况了接口和抽象类的概念、异同和使用规则，从学习的观点来看，我认为这些总结已经足以表达其核心。但是，对于面向对象和软件设计的深入理解，还是建立在不断实践的基础上，Scott说自己每天坚持一个小时用来写Demo，那么我们是不是更应该勤于键盘呢。对于接口和抽象类，请多用而知其然，多想而知其奥吧。
================================================================================

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"关系，即父类和派生类在概念本质上应该是相同的（参考文献〔3〕中有关于"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();
}

或者

 

interface Door {
void open();
void close();
void alarm();
}

那么具有报警功能的AlarmDoor的定义方式如下：

 

class AlarmDoor extends Door {
void open() { … }
void close() { … }
void alarm() { … }
}

或者

 

class AlarmDoor implements Door {
void open() { … }
void close() { … }
void alarm() { … }
}

这种方法违反了面向对象设计中的一个核心原则ISP（Interface Segregation Priciple），在Door的定义中把Door概念本身固有的行为方法和另外一个概念"报警器"的行为方法混在了一起。这样引起的一个问题是那些仅仅依赖于Door这个概念的模块会因为"报警器"这个概念的改变（比如：修改alarm方法的参数）而改变，反之依然。

解决方案二：

既然open、close和alarm属于两个不同的概念，根据ISP原则应该把它们分别定义在代表这两个概念的抽象类中。定义方式有：这两个概念都使用abstract class方式定义；两个概念都使用interface方式定义；一个概念使用abstract class方式定义，另一个概念使用interface方式定义。

显然，由于Java语言不支持多重继承，所以两个概念都使用abstract class方式定义是不可行的。后面两种方式都是可行的，但是对于它们的选择却反映出对于问题领域中的概念本质的理解、对于设计意图的反映是否正确、合理。我们一一来分析、说明。

如果两个概念都使用interface方式来定义，那么就反映出两个问题：1、我们可能没有理解清楚问题领域，AlarmDoor在概念本质上到底是Door还是报警器？2、如果我们对于问题领域的理解没有问题，比如：我们通过对于问题领域的分析发现AlarmDoor在概念本质上和Door是一致的，那么我们在实现时就没有能够正确的揭示我们的设计意图，因为在这两个概念的定义上（均使用interface方式定义）反映不出上述含义。

如果我们对于问题领域的理解是：AlarmDoor在概念本质上是Door，同时它有具有报警的功能。我们该如何来设计、实现来明确的反映出我们的意思呢？前面已经说过，abstract class在Java语言中表示一种继承关系，而继承关系在本质上是"is a"关系。所以对于Door这个概念，我们应该使用abstarct class方式来定义。另外，AlarmDoor又具有报警功能，说明它又能够完成报警概念中定义的行为，所以报警概念可以通过interface方式定义。如下所示：

 

abstract class Door {
abstract void open();
abstract void close()；
}
interface Alarm {
void alarm();
}
class AlarmDoor extends Door implements Alarm {
void open() { … }
void close() { … }
void alarm() { … }
}

这种实现方式基本上能够明确的反映出我们对于问题领域的理解，正确的揭示我们的设计意图。其实abstract class表示的是"is a"关系，interface表示的是"like a"关系，大家在选择时可以作为一个依据，当然这是建立在对问题领域的理解上的，比如：如果我们认为AlarmDoor在概念本质上是报警器，同时又具有Door的功能，那么上述的定义方式就要反过来了。

结论

abstract class和interface是Java语言中的两种定义抽象类的方式，它们之间有很大的相似性。但是对于它们的选择却又往往反映出对于问题领域中的概念本质的理解、对于设计意图的反映是否正确、合理，因为它们表现了概念间的不同的关系（虽然都能够实现需求的功能）。这其实也是语言的一种的惯用法，希望读者朋友能够细细体会。