Josh Bloch在《有效的Java 2d》中说道：

首选接口而非抽象类

一些要点：

可以很容易地对现有类进行修改，以实现新的界面你所要做的就是添加所需的方法（如果还没有）存在并将implements子句添加到类声明。接口是定义混合的理想选择。粗略地说mixin是类可以使用的类型除了“主要”键入“”以声明它提供一些可选行为。例如Comparable是一个mixin接口允许类声明其实例的排序依据其他相互可比较的对象。接口允许构造非分层类型框架。类型层次结构为很适合组织一些事情，但是其他的事情并不是很简单刚性层次。接口通过每类包装的习惯用法。如果您使用抽象类来定义类型留下想要添加的程序员功能，别无选择使用继承。此外，你可以结合这些优点接口和抽象类提供抽象骨架实现类导出的非平凡接口。

另一方面，接口很难发展。如果您向接口添加一个方法，它将破坏它的所有实现。

PS：买这本书。它要详细得多。

用你自己的判断，要聪明。不要总是照别人（像我）说的做。你会听到“更喜欢接口而不是抽象类”，但这取决于实际情况。这取决于班级。

在上面提到的情况下，我们有一个对象层次结构，接口是一个好主意。接口有助于处理这些对象的集合，在实现服务时也有助于使用层次结构中的任何对象。您只需定义一个用于处理层次结构中的对象的契约。

另一方面，当您实现一组共享公共功能的服务时，您可以将公共功能分离为一个完整的单独类，也可以将其移动到一个公共基类中，并使其抽象化，以便没有人可以实例化基类。

还要考虑如何随时间推移支持抽象。接口是固定的：您将一个接口作为任何类型都可以实现的一组功能的契约发布。基类可以随着时间的推移而扩展。这些扩展成为每个派生类的一部分。

感谢Jon Limjap的回答，但我想为接口和抽象基类的概念添加一些解释

接口类型与抽象基类

改编自Pro C#5.0和.NET 4.5 Framework书籍。

接口类型似乎与抽象基类非常相似。回忆起当类被标记为抽象时，它可以定义任意数量的抽象成员来提供所有派生类型的多态接口。然而，即使类确实定义了一组抽象成员，还可以自由定义任意数量的构造函数、字段数据、非抽象成员（使用另一方面，接口只包含抽象成员定义。抽象父类建立的多态接口有一个主要限制因为只有派生类型支持抽象父级定义的成员。然而，在更大范围内软件系统，开发多个没有共同父级的类层次结构是非常常见的超出System.Object。假定抽象基类中的抽象成员仅适用于派生类型，我们无法在不同的层次结构中配置类型以支持相同的多态性界面例如，假设您定义了以下抽象类：

public abstract class CloneableType
{
// Only derived types can support this
// "polymorphic interface." Classes in other
// hierarchies have no access to this abstract
// member.
   public abstract object Clone();
}

给定此定义，只有扩展CloneableType的成员才能支持Clone（）方法如果创建一组不扩展此基类的新类，则无法获得多态界面。此外，您可能还记得C#不支持类的多重继承。因此，如果您想创建一辆小型货车，它是一辆汽车，并且是一种可克隆类型，那么您无法做到：

// Nope! Multiple inheritance is not possible in C#
// for classes.
public class MiniVan : Car, CloneableType
{
}

正如您所猜测的，接口类型起到了拯救作用。定义接口后，可以可以由任何类或结构、任何层次结构、任何命名空间或任何程序集中实现（用任何.NET编程语言编写）。正如您所看到的，接口是高度多态的。考虑System命名空间中定义的名为ICloneable的标准.NET接口。这接口定义了一个名为Clone（）的方法：

public interface ICloneable
{
object Clone();
}

接口有一个明显的优点，即对类来说有点“热交换”。将一个类从一个父类更改为另一个父级通常会导致大量工作，但通常可以删除和更改接口，而不会对实现类产生很大影响。这在您有几个“可能”希望类实现的窄行为集的情况下尤其有用。

这在我的领域尤其适用：游戏编程。基类可能会因继承对象“可能”需要的大量行为而变得臃肿。通过接口，可以轻松地向对象添加或删除不同的行为。例如，如果我为想要反映伤害的对象创建了“IDamageEffects”界面，那么我可以很容易地将其应用于各种游戏对象，并在以后很容易地改变主意。假设我设计了一个要用于“静态”装饰对象的初始类，我最初决定它们是不可破坏的。稍后，我可能会决定，如果它们可以爆炸，那会更有趣，所以我修改了类以实现“IDamageEffects”接口。这比切换基类或创建新的对象层次结构要容易得多。

我通常在需要之前都不会实现。与抽象类相比，我更喜欢接口，因为这提供了更多的灵活性。如果在某些继承类中有共同的行为，我会将其上移并创建一个抽象基类。我不认为两者都有必要，因为它们本质上服务于相同的目的，而且两者都有一种糟糕的代码气味（imho），解决方案被过度设计了。

继承还有其他优点，例如变量能够保存父类或继承类的对象（无需将其声明为泛型，如“object”）。

例如，在.NET WinForms中，大多数UI组件都是从System.Windows.Forms.Control派生的，因此声明为的变量可以“容纳”几乎所有UI元素，无论是按钮、ListView还是其他元素。当然，现在你不能访问项目的所有财产或方法，但你可以拥有所有基本的东西——这可能很有用。