我真的不明白接口存在的原因。据我所知，这是c#中不存在的多继承的一种工作(至少我是这么被告知的)。
我所看到的是，您预定义了一些成员和函数，然后必须在类中再次重新定义它们。从而使接口成为冗余。它只是感觉像句法……嗯，垃圾对我来说(请没有冒犯的意思。Junk是指无用的东西)。
在下面的例子中，我将创建一个名为Pizza的基类，而不是一个接口。
简单示例(取自不同的堆栈溢出贡献)
public interface IPizza
{
public void Order();
}
public class PepperoniPizza : IPizza
{
public void Order()
{
//Order Pepperoni pizza
}
}
public class HawaiiPizza : IPizza
{
public void Order()
{
//Order HawaiiPizza
}
}
当前回答
接口实际上是实现类必须遵循的契约，它实际上是我所知道的几乎所有设计模式的基础。
在您的示例中，创建接口是因为这样就保证实现了比萨饼接口的is A Pizza
public void Order();
在你提到的代码之后，你可以这样写:
public void orderMyPizza(IPizza myPizza) {
//This will always work, because everyone MUST implement order
myPizza.order();
}
这样您使用的是多态性，您所关心的只是对象对order()做出响应。
其他回答
I share your sense that Interfaces are not necessary. Here is a quote from Cwalina pg 80 Framework Design Guidelines "I often here people saying that interfaces specify contracts. I believe this a dangerous myth. Interfaces by themselves do not specify much. ..." He and co-author Abrams managed 3 releases of .Net for Microsoft. He goes on to say that the 'contract' is "expressed" in an implementation of the class. IMHO watching this for decades, there were many people warning Microsoft that taking the engineering paradigm to the max in OLE/COM might seem good but its usefulness is more directly to hardware. Especially in a big way in the 80s and 90s getting interoperating standards codified. In our TCP/IP Internet world there is little appreciation of the hardware and software gymnastics we would jump through to get solutions 'wired up' between and among mainframes, minicomputers, and microprocessors of which PCs were just a small minority. So coding to interfaces and their protocols made computing work. And interfaces ruled. But what does solving making X.25 work with your application have in common with posting recipes for the holidays? I have been coding C++ and C# for many years and I never created one once.
接口定义了某种功能的提供者和相应的使用者之间的契约。它将实现与契约(接口)解耦。您应该了解一下面向对象的体系结构和设计。你可能想从维基百科开始:http://en.wikipedia.org/wiki/Interface_(computing)
接口的主要目的是在您和实现该接口的任何其他类之间建立契约，使您的代码解耦并允许可扩展性。
关键是接口代表一个契约。任何实现类都必须拥有的一组公共方法。从技术上讲，接口只控制语法，即有什么方法，它们得到什么参数以及它们返回什么。通常它们也封装语义，尽管只是通过文档。
然后，您可以拥有一个接口的不同实现，并随意交换它们。在您的示例中，由于每个披萨实例都是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#接口，它也可以是一个抽象类，甚至是一个普通类(如果所有子类都需要共享一些公共代码，这可以派上用场——然而，在大多数情况下，接口就足够了)。
我很惊讶，没有多少文章包含一个最重要的接口原因:设计模式。这是使用契约的更大的前景，尽管它是机器代码的语法装饰(老实说，编译器可能会忽略它们)，但抽象和接口对于OOP、人类理解和复杂的系统架构来说是至关重要的。
让我们把披萨的比喻扩大到一顿完整的大餐。对于所有的食物类别，我们仍然有核心的Prepare()接口，但我们也有针对课程选择(前菜、主菜、甜点)的抽象声明，以及针对食物类型(咸的/甜的、素食的/非素食的、无麸质的等)的不同属性。
基于这些规范，我们可以实现抽象工厂模式来概念化整个过程，但是使用接口来确保只有基础是具体的。其他一切都可以变得灵活或鼓励多态，同时在实现iccourse接口的不同Course类之间保持封装。
如果我有更多的时间，我想画一个完整的例子，或者有人可以为我扩展它，但总的来说，c#接口将是设计这类系统的最佳工具。
