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

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

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

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

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

// 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中的类型。

考虑一下不控制或不拥有基类的情况。

以可视化控件为例，在。net for Winforms中，它们都继承自。net框架中完全定义的基类Control。

让我们假设您从事创建自定义控件的业务。你想要建立新的按钮，文本框，列表视图，网格，等等，你希望他们都有特定的功能独特的控件集。

例如，你可能想要一种通用的方法来处理主题，或者一种通用的方法来处理本地化。

在这种情况下，你不能“只创建一个基类”，因为如果你这样做，你必须重新实现所有与控件相关的东西。

相反，您将从按钮，TextBox, ListView, GridView等下降，并添加您的代码。

但这就产生了一个问题，你现在如何识别哪些控件是“你的”，你如何构建一些代码来表明“对于窗体上所有属于我的控件，将主题设置为X”。

输入接口。

接口是一种查看对象、确定对象是否遵守某种约定的方法。

您可以创建“YourButton”，从Button向下延伸，并添加对所需的所有接口的支持。

这将允许您编写如下代码:

foreach (Control ctrl in Controls)
{
    if (ctrl is IMyThemableControl)
        ((IMyThemableControl)ctrl).SetTheme(newTheme);
}

如果没有接口，这是不可能的，相反，你必须写这样的代码:

foreach (Control ctrl in Controls)
{
    if (ctrl is MyThemableButton)
        ((MyThemableButton)ctrl).SetTheme(newTheme);
    else if (ctrl is MyThemableTextBox)
        ((MyThemableTextBox)ctrl).SetTheme(newTheme);
    else if (ctrl is MyThemableGridView)
        ((MyThemableGridView)ctrl).SetTheme(newTheme);
    else ....
}

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

类比简单解释

无接口(例1):

无接口(例2):

有接口:

需要解决的问题:多态性的目的是什么?

比方说，我是一个建筑工地的领班。我不知道哪个商人会走进来。但我告诉他们该怎么做。

如果是木匠，我会说:搭建木质脚手架。 如果是管道工，我会说:安装管道 如果是人民党政府官员，我说，三袋现金，先生。

上述方法的问题在于:(1)我必须知道谁会走进那扇门，并且根据是谁，我必须告诉他们该做什么。这通常会使代码更难维护或更容易出错。

知道该做什么的含义:

This means if the carpenter's code changes from: BuildScaffolding() to BuildScaffold() (i.e. a slight name change) then I will have to also change the calling class (i.e. the Foreperson class) as well - you'll have to make two changes to the code instead of (basically) just one. With polymorphism you (basically) only need to make one change to achieve the same result. Secondly you won't have to constantly ask: who are you? ok do this...who are you? ok do that.....polymorphism - it DRYs that code, and is very effective in certain situations: with polymorphism you can easily add additional classes of tradespeople without changing any existing code. (i.e. the second of the SOLID design principles: Open-close principle).

解决方案

想象一下这样一个场景:无论谁走进来，我都可以说:“Work()”，他们做着自己擅长的工作:管道工处理管道，电工处理电线，官僚可能专门负责受贿，为其他人做双倍的工作。

这种方法的好处是:(i)我不需要确切地知道谁会走进那扇门——我只需要知道他们是一种手工工人，他们会工作，其次，(ii)我不需要知道任何关于特定行业的信息。手工工人会处理的。

所以不要这样:

if(electrician) then  electrician.FixCablesAndElectricity() 

if(plumber) then plumber.IncreaseWaterPressureAndFixLeaks() 

if(keralaCustoms) then keralaCustoms.askForBribes() 

我可以这样做:

ITradesman tradie = Tradesman.Factory(); // in reality i know it's a plumber, but in the real world you won't know who's on the other side of the tradie assignment.

tradie.Work(); // and then tradie will do the work of a plumber, or electrician etc. depending on what type of tradesman he is. The foreman doesn't need to know anything, apart from telling the anonymous tradie to get to Work()!!

有什么好处?

这样做的好处是，如果木匠等特定的工作要求发生了变化，那么领班就不需要改变他的代码——他不需要知道或关心。重要的是木匠知道Work()是什么意思。其次，如果一种新型的建筑工人来到工地上，那么工头不需要知道任何关于贸易的事情——工头所关心的是建筑工人(.e。焊工、上釉工、瓦工等)可以完成一些工作。

总结

界面允许您让人完成分配给他们的工作，而不需要您确切地知道他们是谁或他们可以做什么。这允许您轻松地添加新的(交易)类型，而无需更改现有的代码(从技术上讲，您确实更改了一点点)，这是面向对象方法相对于更函数式编程方法的真正好处。

如果你不理解上面的任何内容，或者不清楚，请在评论中提问，我会尽量让答案更好。

关键是接口代表一个契约。任何实现类都必须拥有的一组公共方法。从技术上讲，接口只控制语法，即有什么方法，它们得到什么参数以及它们返回什么。通常它们也封装语义，尽管只是通过文档。

然后，您可以拥有一个接口的不同实现，并随意交换它们。在您的示例中，由于每个披萨实例都是IPizza，因此在处理未知披萨类型实例的任何地方都可以使用IPizza。任何类型继承自IPizza的实例都保证是可排序的，因为它有一个Order()方法。

Python is not statically-typed, therefore types are kept and looked up at runtime. So you can try calling an Order() method on any object. The runtime is happy as long as the object has such a method and probably just shrugs and says »Meh.« if it doesn't. Not so in C#. The compiler is responsible for making the correct calls and if it just has some random object the compiler doesn't know yet whether the instance during runtime will have that method. From the compiler's point of view it's invalid since it cannot verify it. (You can do such things with reflection or the dynamic keyword, but that's going a bit far right now, I guess.)

还要注意，通常意义上的接口不一定是c#接口，它也可以是一个抽象类，甚至是一个普通类(如果所有子类都需要共享一些公共代码，这可以派上用场——然而，在大多数情况下，接口就足够了)。

接口用于应用不同类之间的连接。例如，你有一个关于汽车和树的类;

public class Car { ... }

public class Tree { ... }

您希望为这两个类添加一个可燃功能。但是每个职业都有自己的燃烧方式。所以你只要做;

public class Car : IBurnable
{
public void Burn() { ... }
}

public class Tree : IBurnable
{
public void Burn() { ... }
}