我真的不明白接口存在的原因。据我所知,这是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
}
}
如果我正在使用一个API来绘制形状,我可能想使用DirectX或图形调用,或OpenGL。因此,我将创建一个接口,它将从您调用的内容中抽象出我的实现。
所以你调用一个工厂方法:MyInterface i = MyGraphics.getInstance()。然后,你有一个契约,所以你知道你可以在MyInterface中期望什么功能。你可以调用i。drawrectangle或i。drawcube并且知道如果你把一个库换成另一个库,函数是被支持的。
如果您正在使用依赖注入,这就变得更加重要,因为您可以在XML文件中交换实现。
所以,你可能有一个加密库可以导出,供一般使用,而另一个加密库只出售给美国公司,区别在于你改变了配置文件,而程序的其余部分不会改变。
这在。net中的集合中被大量使用,就像你应该只使用,例如,列表变量,不要担心它是一个数组列表还是LinkedList。
只要您编写了接口代码,那么开发人员就可以更改实际的实现,而程序的其余部分则保持不变。
这在单元测试时也很有用,因为您可以模拟出整个接口,因此,我不需要访问数据库,而是只返回静态数据的模拟出来的实现,因此我可以测试我的方法,而不用担心数据库是否需要维护。
我很惊讶,没有多少文章包含一个最重要的接口原因:设计模式。这是使用契约的更大的前景,尽管它是机器代码的语法装饰(老实说,编译器可能会忽略它们),但抽象和接口对于OOP、人类理解和复杂的系统架构来说是至关重要的。
让我们把披萨的比喻扩大到一顿完整的大餐。对于所有的食物类别,我们仍然有核心的Prepare()接口,但我们也有针对课程选择(前菜、主菜、甜点)的抽象声明,以及针对食物类型(咸的/甜的、素食的/非素食的、无麸质的等)的不同属性。
基于这些规范,我们可以实现抽象工厂模式来概念化整个过程,但是使用接口来确保只有基础是具体的。其他一切都可以变得灵活或鼓励多态,同时在实现iccourse接口的不同Course类之间保持封装。
如果我有更多的时间,我想画一个完整的例子,或者有人可以为我扩展它,但总的来说,c#接口将是设计这类系统的最佳工具。
class Program {
static void Main(string[] args) {
IMachine machine = new Machine();
machine.Run();
Console.ReadKey();
}
}
class Machine : IMachine {
private void Run() {
Console.WriteLine("Running...");
}
void IMachine.Run() => Run();
}
interface IMachine
{
void Run();
}
让我从另一个角度来描述一下。让我们根据上面的例子来创建一个故事;
程序、机器和IMachine是我们故事的演员。程序想要运行,但它没有这个能力,而机器知道如何运行。机器和IMachine是最好的朋友,但程序和机器没有说话的关系。于是程序和IMachine做了一个交易,决定IMachine通过观察机器(就像一个反射器)来告诉程序如何运行。
Program在IMachine的帮助下学习如何运行。
接口提供通信和开发松散耦合的项目。
PS:我把具体类的方法作为私有。我在这里的目标是通过防止访问具体的类属性和方法来实现松耦合,只允许通过接口访问它们。(所以我明确地定义了接口的方法)。