对我来说，刚开始的时候，只有当你不再把它们看作是让你的代码更容易/更快编写的东西时，它们的意义才变得清晰——这不是它们的目的。它们有很多用途:

(这里就没有披萨的比喻了，因为这个比喻的用法不太容易想象)

假设你正在屏幕上制作一款简单的游戏，游戏中会有与你互动的生物。

答:通过在前端和后端实现之间引入松散耦合，它们可以使您的代码在将来更容易维护。

你可以这样写，因为这里只会有喷子:

// This is our back-end implementation of a troll
class Troll
{
    void Walk(int distance)
    {
        //Implementation here
    }
}

前端:

function SpawnCreature()
{
    Troll aTroll = new Troll();
    
    aTroll.Walk(1);
}

两周后，市场营销决定你也需要半兽人，因为他们在twitter上看到了他们，所以你必须做如下事情:

class Orc
{
    void Walk(int distance)
    {
        //Implementation (orcs are faster than trolls)
    }
}

前端:

void SpawnCreature(creatureType)
{
    switch(creatureType)
    {
         case Orc:

           Orc anOrc = new Orc();
           anORc.Walk();

          case Troll:

            Troll aTroll = new Troll();
             aTroll.Walk();
    }
}

你可以看到这是如何变得混乱的。你可以在这里使用一个接口，这样你的前端就会被编写一次(这里是重要的部分)测试，然后你可以根据需要插入更多的后端项目:

interface ICreature
{
    void Walk(int distance)
}

public class Troll : ICreature
public class Orc : ICreature 

//etc

前端则为:

void SpawnCreature(creatureType)
{
    ICreature creature;

    switch(creatureType)
    {
         case Orc:

           creature = new Orc();

          case Troll:

            creature = new Troll();
    }

    creature.Walk();
}

前端现在只关心接口ICreature -它不关心喷子或兽人的内部实现，而只关心他们实现ICreature的事实。

从这个角度来看，需要注意的一点是，您也可以很容易地使用抽象生物类，从这个角度来看，这具有相同的效果。

你可以将创建的内容提取到工厂:

public class CreatureFactory {

 public ICreature GetCreature(creatureType)
 {
    ICreature creature;

    switch(creatureType)
    {
         case Orc:

           creature = new Orc();

          case Troll:

            creature = new Troll();
    }

    return creature;
  }
}

我们的前端会变成:

CreatureFactory _factory;

void SpawnCreature(creatureType)
{
    ICreature creature = _factory.GetCreature(creatureType);

    creature.Walk();
}

现在，前端甚至不需要有实现Troll和Orc的库的引用(假设工厂在一个单独的库中)——它不需要知道任何关于它们的信息。

B:假设你拥有在你的同质数据结构中只有某些生物才有的功能，例如:

interface ICanTurnToStone
{
   void TurnToStone();
}

public class Troll: ICreature, ICanTurnToStone

前端可以是:

void SpawnCreatureInSunlight(creatureType)
{
    ICreature creature = _factory.GetCreature(creatureType);

    creature.Walk();

    if (creature is ICanTurnToStone)
    {
       (ICanTurnToStone)creature.TurnToStone();
    }
}

C:依赖注入用法

大多数依赖注入框架在前端代码和后端实现之间存在非常松散的耦合时才能工作。如果我们以上面的工厂为例，让我们的工厂实现一个接口:

public interface ICreatureFactory {
     ICreature GetCreature(string creatureType);
}

我们的前端可以通过构造函数注入(例如MVC API控制器)(通常):

public class CreatureController : Controller {

   private readonly ICreatureFactory _factory;

   public CreatureController(ICreatureFactory factory) {
     _factory = factory;
   }

   public HttpResponseMessage TurnToStone(string creatureType) {

       ICreature creature = _factory.GetCreature(creatureType);
   
       creature.TurnToStone();

       return Request.CreateResponse(HttpStatusCode.OK);
   }
}

使用我们的DI框架(例如Ninject或Autofac)，我们可以设置它们，以便在运行时在构造函数中需要ICreatureFactory时创建一个CreatureFactory实例——这使我们的代码美观而简单。

这也意味着当我们为控制器编写单元测试时，我们可以提供一个模拟的ICreatureFactory(例如，如果具体实现需要访问DB，我们不希望我们的单元测试依赖于它)，并轻松地测试控制器中的代码。

D:还有其他用途，例如，你有两个项目A和B，由于“遗留”原因，它们没有很好地组织起来，而A有B的参考。

然后在B中发现需要调用a中已经存在的方法的功能。由于您获得的是循环引用，因此不能使用具体实现来实现。

你可以在B中声明一个接口，然后由A中的类实现。你在B中的方法可以被传递一个实现接口的类的实例，即使具体对象是a中的类型。

我知道我已经迟到了。(差不多九年了)，但如果有人想要简单的解释，你可以这样说:

简单地说，当你知道一个对象可以做什么，或者我们要在一个对象上实现什么函数时，你就使用接口。使用实例插入、更新和删除。

interface ICRUD{
      void InsertData(); // will insert data
      void UpdateData(); // will update data
      void DeleteData(); // will delete data
}

重要提示:接口总是公共的。

希望这能有所帮助。

考虑到你不能在c#中使用多重继承，然后再看看你的问题。

这么多答案! 尽我所能。呵呵。

首先，你可以使用一个具体的基类和派生类。在这种情况下，你将不得不在基类中为Prepare方法做一个空的或无用的实现，同时使这个方法为虚的，然后派生类将为自己重写这个Prepare方法。在这种情况下，在基类中实现Prepare是无用的。

选择使用接口的原因是必须定义契约，而不是实现。

有一个IPizza类型，它提供了一个功能来准备。这是合同。它是如何准备的是实现，这不是你的把关。这是各种Pizza实现的责任。 这里首选接口或抽象类而不是具体基类，因为您必须创建一个抽象，即Prepare方法。不能在具体基类中创建抽象方法。

现在你可能会说，为什么不用抽象类呢?

所以，当你需要实现100%的抽象时，你需要使用接口。但是当你需要一些抽象和具体的实现时，选择抽象类。它的意思。

例子:假设你所有的披萨都有底料，底料的准备过程是相同的。然而，所有披萨的种类和配料都有所不同。在这种情况下，您可以使用一个抽象方法Prepare和一个具体方法PreparePizzaBase创建一个抽象类。

public abstract class Pizza{
    // concrete method which is common to all pizzas.
    public PizzaBase PreparePizzaBase(){
        // code for pizza base preparation.
    }
    public abstract void Prepare();
}

public class DeluxePizza: Pizza{
    public void Prepare(){
        var base=PreparePizzaBase();
        // prepare deluxe pizza on pizza base.
    }
}

考虑接口的最简单方法是认识继承的意义。如果类CC继承了类C，这意味着:

类CC可以使用类C的任何public或protected成员，就像它们是自己的一样，因此只需要实现父类中不存在的东西。 对CC的引用可以传递或分配给期望对C的引用的例程或变量。

遗传的这两个功能在某种意义上是相互独立的;虽然继承同时应用这两个，但也可以应用第二个而不应用第一个。这很有用，因为允许一个对象从两个或多个不相关的类继承成员要比允许一种类型可以替代多种类型复杂得多。

接口有点像抽象基类，但有一个关键的区别:继承基类的对象不能继承任何其他类。相反，一个对象可以实现一个接口，而不影响它继承任何所需类或实现任何其他接口的能力。

One nice feature of this (underutilized in the .net framework, IMHO) is that they make it possible to indicate declaratively the things an object can do. Some objects, for example, will want data-source object from which they can retrieve things by index (as is possible with a List), but they won't need to store anything there. Other routines will need a data-depository object where they can store things not by index (as with Collection.Add), but they won't need to read anything back. Some data types will allow access by index, but won't allow writing; others will allow writing, but won't allow access by index. Some, of course, will allow both.

If ReadableByIndex and Appendable were unrelated base classes, it would be impossible to define a type which could be passed both to things expecting a ReadableByIndex and things expecting an Appendable. One could try to mitigate this by having ReadableByIndex or Appendable derive from the other; the derived class would have to make available public members for both purposes, but warn that some public members might not actually work. Some of Microsoft's classes and interfaces do that, but that's rather icky. A cleaner approach is to have interfaces for the different purposes, and then have objects implement interfaces for the things they can actually do. If one had an interface IReadableByIndex and another interface IAppendable, classes which could do one or the other could implement the appropriate interfaces for the things they can do.

什么?

接口基本上是一个契约，所有实现接口的类都应该遵循这个契约。它们看起来像一个类，但没有实现。

在c#中，接口名称的约定是由前缀“I”定义的，所以如果你想要一个名为shapes的接口，你可以将它声明为IShapes

为什么?

提高代码的可重用性

假设你想画圆，三角形。 你可以把它们组合在一起，称为形状，并有方法来绘制圆形和三角形 但有具体的实现将是一个坏主意，因为明天你可能会决定有2个形状矩形和正方形。现在，当您添加它们时，很可能会破坏代码的其他部分。

使用Interface，您可以将不同的实现与契约隔离开来

---

现场场景第一天

你被要求创建一个应用程序来绘制圆形和三角形

interface IShapes
{
   void DrawShape();
   
 }

class Circle : IShapes
{
    
    public void DrawShape()
    {
        Console.WriteLine("Implementation to Draw a Circle");
    }
}

Class Triangle: IShapes
{
     public void DrawShape()
    {
        Console.WriteLine("Implementation to draw a Triangle");
    }
}

static void Main()
{
     List <IShapes> shapes = new List<IShapes>();
        shapes.Add(new Circle());
        shapes.Add(new Triangle());

        foreach(var shape in shapes)
        {
            shape.DrawShape();
        }
}

现场场景第二天

如果你被要求添加Square和Rectangle，你所要做的就是在Square: IShapes类中创建它的实现，并在Main中添加到列表形状。添加(新广场());