抽象类处理有效地打包类功能，而接口用于意图/契约/通信，并且应该与其他类/模块共享。

使用抽象类作为契约和（部分）契约实现者违反了SRP。使用抽象类作为契约（依赖关系）限制了创建多个抽象类以获得更好的重用性。

在下面的示例中，使用抽象类作为OrderManager的合同会产生问题，因为我们有两种不同的处理订单的方式-基于客户类型和类别（客户可以是直接或间接的，也可以是黄金或白银）。因此，接口用于契约，抽象类用于不同的工作流实施

public interface IOrderProcessor
{
    bool Process(string orderNumber);
}

public abstract class CustomerTypeOrderProcessor: IOrderProcessor
{
    public bool Process(string orderNumber) => IsValid(orderNumber) ? ProcessOrder(orderNumber) : false;

    protected abstract bool ProcessOrder(string orderNumber);

    protected abstract bool IsValid(string orderNumber);
}

public class DirectCustomerOrderProcessor : CustomerTypeOrderProcessor
{
    protected override bool IsValid(string orderNumber) => string.IsNullOrEmpty(orderNumber); 

    protected override bool ProcessOrder(string orderNumber) => true; 
}

public class InDirectCustomerOrderProcessor : CustomerTypeOrderProcessor
{
    protected override bool IsValid(string orderNumber) => orderNumber.StartsWith("EX");

    protected override bool ProcessOrder(string orderNumber) => true;
}

public abstract class CustomerCategoryOrderProcessor : IOrderProcessor
{
    public bool Process(string orderNumber) => ProcessOrder(GetDiscountPercentile(orderNumber), orderNumber);

    protected abstract int GetDiscountPercentile(string orderNumber);

    protected abstract bool ProcessOrder(int discount, string orderNumber);
}

public class GoldCustomer : CustomerCategoryOrderProcessor
{
    protected override int GetDiscountPercentile(string orderNumber) => 15;

    protected override bool ProcessOrder(int discount, string orderNumber) => true;

}

public class SilverCustomer : CustomerCategoryOrderProcessor
{
    protected override int GetDiscountPercentile(string orderNumber) => 10;

    protected override bool ProcessOrder(int discount, string orderNumber) => true;

}

public class OrderManager
{
    private readonly IOrderProcessor _orderProcessor;// Not CustomerTypeOrderProcessor or CustomerCategoryOrderProcessor 

    //Using abstract class here would create problem as we have two different abstract classes
    public OrderManager(IOrderProcessor orderProcessor) => _orderProcessor = orderProcessor;
}

面试官们正在寻找一棵奇怪的树。对于像C#和Java这样的语言，这是有区别的，但在其他语言中，像C++没有区别。OO理论并没有区分这两者，仅仅是语言的语法。

抽象类是一个同时具有实现和接口（纯虚拟方法）的类，将被继承。接口通常没有任何实现，只有纯虚拟函数。

在C#或Java中，没有任何实现的抽象类与接口的区别仅在于用于从其继承的语法以及只能从其中继承的事实。

虽然您的问题表明它是针对“通用OO”的，但它似乎真正关注的是.NET对这些术语的使用。

在.NET中（类似于Java）：

接口可以没有状态或实现实现接口的类必须提供该接口的所有方法的实现抽象类可以包含状态（数据成员）和/或实现（方法）抽象类可以在不实现抽象方法的情况下继承（尽管这样的派生类本身是抽象的）接口可能是多继承的，抽象类可能不是（这可能是接口与abtract类分开存在的关键具体原因——它们允许实现多继承，从而消除了一般MI的许多问题）。

作为通用OO术语，差异不一定定义明确。例如，有些C++程序员可能持有类似的严格定义（接口是抽象类的严格子集，不能包含实现），而有些人可能会说，具有某些默认实现的抽象类仍然是接口，或者非抽象类仍然可以定义接口。

事实上，有一种叫做非虚拟接口（NVI）的C++习惯用法，其中公共方法是“thunk”到私有虚拟方法的非虚拟方法：

http://www.gotw.ca/publications/mill18.htmhttp://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Non-虚拟界面（_I）

从我的另一个答案来看，主要是关于何时使用一个而不是另一个：

根据我的经验，界面是最好的有几个类时使用每个都需要对相同的方法，以便可由其他代码互换使用将针对这些类的公共接口。最好的当协议很重要，但底层逻辑可能不同于每个类别。如果你不是复制逻辑，考虑抽象类或标准类继承相反

接口类型与抽象基类

改编自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();
}

打个比方吧：当我在空军时，我参加了飞行员培训，成为了一名美国空军飞行员。当时我没有资格驾驶任何飞机，必须参加飞机类型的训练。一旦我获得资格，我就是一名飞行员（抽象类）和一名C-141飞行员（具体类）。在我的一项任务中，我被赋予了一项额外的职责：安全员。现在我仍然是一名飞行员和C-141飞行员，但我也履行了安全员的职责（可以说，我执行了ISafetyOfficer）。飞行员不需要是安全员，其他人也可以这样做。

所有美国空军飞行员都必须遵守某些空军规定，所有C-141（或F-16或T-38）飞行员都是“美国空军飞行员”。任何人都可以成为安全员。因此，总结如下：

Pilot：抽象类C-141试验：混凝土等级ISafety Officer:接口

补充说明：这是一个类比，以帮助解释概念，而不是编码建议。看到下面的各种评论，讨论很有趣。