两者都是类定义的契约:

结论1:两种意图都是对象泛化

在定义抽象类时，它们也可以有默认实现。

结论2:区分存在于行为泛化设计中

在使用抽象类时，类只能从一个抽象类继承

结论3:抽象类在应用上存在局限性。它的意思是 行为概括的局限性。

最后结论-何时使用哪个:区分是在行为泛化层面

在类的行为设计中，如果功能在确定的类之间只是概念上的限制，换句话说，在确定的类之间是共享的，则使用抽象类。但如果功能比确定类更通用，或者我们可以/想要向其他类添加功能，则使用接口作为契约。

什么时候选择抽象类而不是接口?

如果计划在程序/项目的整个生命周期中更新基类，最好允许基类是一个抽象类 如果有人试图为层次结构中密切相关的对象构建主干，那么使用抽象类是非常有益的

什么时候选择接口而不是抽象类?

如果不需要处理大量的层次结构类型的框架，那么接口将是一个很好的选择 因为抽象类不支持多重继承(菱形问题)，所以接口可以挽救局面

在Java中，您可以从一个(抽象)类继承来“提供”功能，并且可以实现许多接口来“确保”功能

我为此写了一篇文章:

抽象类和接口

总结:

当我们谈论抽象类时，我们是在定义对象类型的特征;指定对象是什么。

当我们谈论接口和定义我们承诺提供的功能时，我们谈论的是建立一个关于对象可以做什么的契约。

我写过一篇关于何时使用抽象类和何时使用接口的文章。除了“一个是a……”之外，他们之间还有很多不同之处。一个能做……”。对我来说，这些都是事先准备好的答案。我提到了使用它们中的任何一种的一些原因。希望能有所帮助。

http://codeofdoom.com/wordpress/2009/02/12/learn-this-when-to-use-an-abstract-class-and-an-interface/

我的观点是:

接口基本上定义了一个契约，任何实现类都必须遵守(实现接口成员)。它不包含任何代码。

另一方面，抽象类可以包含代码，并且可能有一些标记为抽象的方法，继承类必须实现这些方法。

我很少使用抽象类的情况是，当我有一些默认功能时，继承类可能对重写不感兴趣，比如一个抽象基类，一些专门的类继承自它。

示例(非常基本的一个!):考虑一个名为Customer的基类，它具有抽象方法，如CalculatePayment()， CalculateRewardPoints()和一些非抽象方法，如GetName()， SavePaymentDetails()。

像RegularCustomer和GoldCustomer这样的专门的类将继承自Customer基类，并实现它们自己的CalculatePayment()和CalculateRewardPoints()方法逻辑，但是重用GetName()和SavePaymentDetails()方法。

您可以向抽象类(即非抽象方法)添加更多功能，而不会影响使用旧版本的子类。然而，向接口添加方法会影响实现它的所有类，因为它们现在需要实现新添加的接口成员。

具有所有抽象成员的抽象类类似于接口。