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

首先，你可以使用一个具体的基类和派生类。在这种情况下，你将不得不在基类中为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.
    }
}

接口用于驱动一致性，以一种松散耦合的方式，这使得它不同于紧密耦合的抽象类。这就是为什么它通常也被定义为合同。实现接口的任何类都必须遵守接口定义的“规则/语法”，并且其中没有具体的元素。

我将给出一个下图所支持的例子。

Imagine in a factory there are 3 types of machines.A rectangle machine,a triangle machine and a polygon machine.Times are competitive and you want to streamline operator training.You just want to train them in one methodology of starting and stopping machines so you have a green start button and red stop button.So now across 3 different machines you have a consistent way of starting and stopping 3 different types of machines.Now imagine these machines are classes and the classes need to have start and stop methods,how you going to drive consistency across these classes which can be very different? Interface is the answer.

一个简单的例子来帮助你可视化，有人可能会问为什么不用抽象类呢?有了接口，对象不必直接相关或继承，你仍然可以在不同的类之间保持一致性。

public interface IMachine
{
    bool Start();
    bool Stop();
}

public class Car : IMachine
{
    public bool Start()
    {
        Console.WriteLine("Car started");
        return true;
    }

    public bool Stop()
    {
        Console.WriteLine("Car stopped");
        return false;
    }
}

public class Tank : IMachine
{
    public bool Start()
    {
        Console.WriteLine("Tank started");
        return true;
    }

    public bool Stop()
    {
        Console.WriteLine("Tank stopped");
        return false;
    }
}

class Program
{
    static void Main(string[] args)
    {
        var car = new Car();
        car.Start();
        car.Stop();

        var tank = new Tank();
        tank.Start();
        tank.Stop();

    }
}

考虑到你不能在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.

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

然后，您可以拥有一个接口的不同实现，并随意交换它们。在您的示例中，由于每个披萨实例都是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#接口，它也可以是一个抽象类，甚至是一个普通类(如果所有子类都需要共享一些公共代码，这可以派上用场——然而，在大多数情况下，接口就足够了)。