关于C#，在某些意义上，接口和抽象类可以互换。然而，区别在于：i）接口不能实现代码；ii）由于这一点，接口不能进一步调用堆栈上的子类；以及iii）抽象类只能在类上继承，而多个接口可以在类上实现。

接口

大多数语言允许您实现多个接口修改接口是一项突破性的更改。所有实现都需要重新编译/修改。所有成员都是公共的。实现必须实现所有成员。接口有助于解耦。您可以使用模拟框架模拟接口后面的任何内容接口通常表示一种行为接口实现彼此分离/隔离

基类

允许您添加一些通过派生免费获得的默认实现（从C#8.0通过接口可以获得默认实现）除了C++，您只能从一个类派生。即使可以从多个类中选择，这通常也是一个坏主意。更改基类相对容易。派生不需要做任何特殊的事情基类可以声明可由派生访问的受保护函数和公共函数抽象基类不能像接口那样容易被模仿基类通常表示类型层次结构（IS A）类派生可能会依赖于一些基本行为（具有复杂的父实现知识）。如果你对一个人的基本实现进行更改并打破其他人，事情可能会很混乱。

资料来源：http://jasonroell.com/2014/12/09/interfaces-vs-abstract-classes-what-should-you-use/

C#是一种奇妙的语言，在过去的14年中不断成熟和发展。这对我们开发人员来说很好，因为一种成熟的语言为我们提供了大量的语言特性，供我们使用。

然而，权力大了，责任大了。其中一些功能可能被误用，或者有时很难理解为什么您会选择使用一个功能而不是另一个功能。多年来，我看到许多开发人员都在纠结于一个特性，那就是什么时候选择使用接口或者选择使用抽象类。两者都有各自的优点和缺点，以及使用它们的正确时间和地点。但我们如何决定？？？

两者都提供了类型之间公共功能的重用。最明显的区别是，接口不提供其功能的实现，而抽象类允许您实现一些“基本”或“默认”行为，然后可以在必要时使用类派生类型“覆盖”此默认行为。

这一切都很好，并且提供了代码的重用，并且遵循了软件开发的DRY（不要重复自己）原则。当你有一种“是”的关系时，抽象类很好用。

例如：金毛寻回犬是一种狗。贵宾犬也是。它们都会吠叫，就像所有的狗一样。然而，您可能需要指出，贵宾犬公园与“默认”狗叫有明显不同。因此，您可以执行以下操作：

public abstract class Dog
{
      public virtual void Bark()
      {
        Console.WriteLine("Base Class implementation of Bark");
      }
}

public class GoldenRetriever : Dog
{
   // the Bark method is inherited from the Dog class
}

public class Poodle : Dog
{
  // here we are overriding the base functionality of Bark with our new implementation
  // specific to the Poodle class
  public override void Bark()
  {
     Console.WriteLine("Poodle's implementation of Bark");
  }
}

// Add a list of dogs to a collection and call the bark method.

void Main()
{
    var poodle = new Poodle();
    var goldenRetriever = new GoldenRetriever();

    var dogs = new List<Dog>();
    dogs.Add(poodle);
    dogs.Add(goldenRetriever);

    foreach (var dog in dogs)
    {
       dog.Bark();
    }
}

// Output will be:
// Poodle's implementation of Bark
// Base Class implementation of Bark

// 

正如您所看到的，这将是一种保持代码干燥的好方法，并允许在任何类型只能依赖默认Bark而不是特殊情况实现时调用基类实现。GoldenRetriever、Boxer、Lab等类都可以免费继承“默认”（低音类）Bark，因为它们实现了Dog抽象类。

但我相信你已经知道了。

您来到这里是因为您想了解为什么您可能希望选择一个接口而不是抽象类，反之亦然。嗯，您可能希望选择接口而不是抽象类的一个原因是，当您没有或希望阻止默认实现时。这通常是因为实现接口的类型与“是”关系无关。事实上，除了每种类型“能够”或“有能力”做某事或拥有某事这一事实之外，它们根本不必是相关的。

那到底是什么意思？嗯，举个例子：人不是鸭子……鸭子也不是人。很明显。然而，鸭子和人类都有游泳的“能力”（考虑到人类在一年级通过了游泳课程：）。此外，由于鸭子不是人，反之亦然，这不是“是一种”关系，而是“能够”关系，我们可以使用一个界面来说明：

// Create ISwimable interface
public interface ISwimable
{
      public void Swim();
}

// Have Human implement ISwimable Interface
public class Human : ISwimable

     public void Swim()
     {
        //Human's implementation of Swim
        Console.WriteLine("I'm a human swimming!");
     }

// Have Duck implement ISwimable interface
public class Duck: ISwimable
{
     public void Swim()
     {
          // Duck's implementation of Swim
          Console.WriteLine("Quack! Quack! I'm a Duck swimming!")
     }
}

//Now they can both be used in places where you just need an object that has the ability "to swim"

public void ShowHowYouSwim(ISwimable somethingThatCanSwim)
{
     somethingThatCanSwim.Swim();
}

public void Main()
{
      var human = new Human();
      var duck = new Duck();

      var listOfThingsThatCanSwim = new List<ISwimable>();

      listOfThingsThatCanSwim.Add(duck);
      listOfThingsThatCanSwim.Add(human);

      foreach (var something in listOfThingsThatCanSwim)
      {
           ShowHowYouSwim(something);
      }
}

 // So at runtime the correct implementation of something.Swim() will be called
 // Output:
 // Quack! Quack! I'm a Duck swimming!
 // I'm a human swimming!

使用上面的代码这样的接口将允许您将对象传递给“能够”执行某些操作的方法。代码不在乎它是如何做到的……它只知道它可以对该对象调用Swim方法，并且该对象将根据其类型知道在运行时采取的行为。

再次，这有助于代码保持干燥，这样您就不必编写多个调用对象的方法来预成型相同的核心函数（ShowHowHumanSwims（人类）、ShowHowDuckSwims（鸭子）等）

在这里使用接口允许调用方法不必担心行为是什么类型或如何实现的。它只是知道，给定接口，每个对象都必须实现Swim方法，因此在自己的代码中调用它是安全的，并允许在自己的类中处理Swim方法的行为。

摘要：

因此，我的主要经验法则是，当你想为一个类层次结构或/和你正在处理的类或类型实现一个“默认”功能时，使用一个抽象类。

另一方面，如果你没有“是一种”关系，但类型共享“能力”来做某事或拥有某事（例如，鸭子“不是”人类“。然而，鸭子和人类共享“游泳能力”），则使用界面。

抽象类和接口之间需要注意的另一个区别是，一个类可以实现一对多接口，但一个类只能从一个抽象类（或任何类）继承。是的，您可以嵌套类并具有继承层次结构（许多程序都这样做，也应该这样做），但不能在一个派生类定义中继承两个类（这一规则适用于C#。在其他一些语言中，您可以这样做，通常是因为这些语言中缺少接口）。

还请记住，使用接口时要遵守接口隔离原则（ISP）。ISP表示，不应强迫任何客户端依赖它不使用的方法。因此，接口应该专注于特定的任务，并且通常非常小（例如IDisposable、IComparable）。

另一个提示是，如果您正在开发小而简洁的功能，请使用接口。如果要设计大型功能单元，请使用抽象类。

希望这能为一些人扫清障碍！

此外，如果你能想出任何更好的例子或想指出什么，请在下面的评论中这样做！

这是非常特定于.NET的，但《框架设计指南》一书认为，一般来说，类在不断发展的框架中提供了更多的灵活性。一旦一个接口交付，您就没有机会在不破坏使用该接口的代码的情况下更改它。然而，对于类，你可以修改它，而不是破坏链接到它的代码。只要你做了正确的修改，包括添加新的功能，你就可以扩展和发展你的代码。

Krzysztof Cwalina在第81页上说：

在.NETFramework的三个版本中，我已经与我们团队中的许多开发人员讨论了这一指南。他们中的许多人，包括那些最初不同意该指南的人，都表示他们后悔将一些API作为接口提供。我甚至没有听说过一个案例，其中有人后悔他们运送了一节课。

也就是说，当然有接口的地方。作为一般准则，始终提供接口的抽象基类实现，作为实现接口的方法的示例。在最佳情况下，基类将节省大量工作。

当我第一次开始学习面向对象编程时，我犯了一个简单的、可能也是常见的错误，即使用继承来共享公共行为——即使这种行为对对象的本质来说并不重要。

为了进一步建立这个问题中经常使用的例子，有很多东西都是可拍的——女朋友、汽车、毛毯所以我可能有一个Petable类提供了这种常见的行为，以及从中继承的各种类。

然而，可拍不是这些物体的本质的一部分。还有很多更重要的概念对他们的天性至关重要——女朋友是人，汽车是陆地车辆，猫是哺乳动物。。。

行为应该首先被分配给接口（包括类的默认接口），并且只有当它们（a）对于作为更大类的子集的一大群类来说是公共的时，才应该被提升为基类——在相同的意义上，“猫”和“人”是“哺乳动物”的子集。

问题是，当你比我一开始更了解面向对象设计之后，你通常会自动完成这项工作，甚至不用考虑它。因此，“代码到接口，而不是抽象类”这句话的真实性变得如此明显，你很难相信任何人都会不厌其烦地说出它，并开始尝试将其他含义解读到其中。

我想补充的另一点是，如果一个类是纯抽象的-没有非抽象的、非继承的成员或方法暴露给子级、父级或客户端-那么为什么它是一个类？它可以被替换，在某些情况下被接口替换，在其他情况下被Null替换。

除了那些提到IPet/PetBase实现的注释之外，在某些情况下，提供访问器帮助器类可能非常有价值。

IPet/PetBase风格假设您有多个实现，从而增加了PetBase的价值，因为它简化了实现。然而，如果您有多个客户端，则提供一个类帮助来帮助使用接口，可以通过使接口更容易使用来降低成本。