使用Interface的优点是什么?

本文关键字：是什么 Interface 使用 | 更新日期: 2023-09-27 17:50:22

使用Interface有什么用?

我听说它是用来代替多重继承的，数据隐藏也可以用它来完成。

是否有其他优势，在哪里使用接口，程序员如何识别需要的接口?

explicit interface implementation和implicit interface implementation有什么不同?

使用Interface的优点是什么?

为了解决隐式/显式问题，我们假设两个不同的接口有相同的声明:

interface IBiographicalData
    {
       string LastName
       {
          get;
          set;
       }
    }
    interface ICustomReportData
    {
       string LastName
       {
          get;
          set;
       }
    }

你有一个实现两个接口的类:

class Person : IBiographicalData, ICustomReportData
{
    private string lastName;
    public string LastName
    {
        get { return lastName; }
        set { lastName = value; }
    }
}

类Person 隐式地实现了这两个接口，因为使用以下代码可以得到相同的输出:

Person p = new p();
IBiographicalData iBio = (IBiographicalData)p;
ICustomReportData iCr = (ICustomReportData)p;
Console.WriteLine(p.LastName);
Console.WriteLine(iBio.LastName);
Console.WriteLine(iCr.LastName);

但是，要显式地实现，可以这样修改Person类:

class Person : IBiographicalData, ICustomReportData
{
    private string lastName;
    public string LastName
    {
        get { return lastName; }
        set { lastName = value; }
    }
    public string ICustomReportData.LastName
    {
        get { return "Last Name:" + lastName; }
        set { lastName = value; }
    }
}

现在代码:

Console.WriteLine(iCr.LastName);

将以"Last Name:"作为前缀。

http://blogs.msdn.com/b/mhop/archive/2006/12/12/implicit-and-explicit-interface-implementations.aspx

接口对于

非常有用

依赖注入
控制反转
测试隔离/gh>

接口只是将类API的描述与其实现分开。它是关于关注点的分离，这是任何健壮的软件项目的基础。您可以替换实现类而不破坏任何其他代码。

这特别有用的一个领域是单元测试，因为它允许您模拟出您不想测试的接口作为给定测试用例的一部分。

让完全不相关的类实现相同的接口还允许你编写可以操作不同层次结构中的不同类的方法(即除了对象之外没有共同的祖先)，而不必将对象作为它们的类型。例如，你可以编写一个方法，接受IEnumerable，并传递List, Array等。如果没有接口或公共基类型，这是不可能的(除非从对象进行强制转换)。

用最基本的术语来说，我们回到OOP 101:

继承:对象B是对象a的"一种"类型。对象a实现的行为和方法由对象B继承、实现和所有(有一些重写的空间)。

Interface:对象A和对象B都是由公共接口表示的抽象对象的"类似行为"示例。詹姆斯·冈特使用了上面列举的例子。其他的例子可能是IPrintable, IDisposable等。

对于实现这些接口的任何给定类，其实现可能会有很大的不同(考虑如何在使用dispose方法的不同类中实现IDisposable)。然而，客户端代码不需要知道或关心实际对象的类型是什么——代码可以简单地通过接口访问所需的属性和方法。

继承通常被视为解决许多编码问题的"神奇"答案，但也被广泛误用为避免编写更多代码的手段。我不同意user492238的观点，即通过接口完成的事情可以通过继承轻松完成。这种方法常常会把你逼入绝境。而且，正如Jodrell所观察到的，多重继承并不是。net的特性(在我看来，这是正确的)。

当您发现自己跨几个(或许多)不相关的类实现相同的行为时，请考虑定义一个为该行为提供API的接口。你可能有几个类:人，动物，建筑等。所有这些都可能需要一个方法来提供可打印的输出。你也可以有一个接受IPrintableObject作为参数的方法。在这种情况下，你可以在任何需要打印的类中实现IPrintableObject，在每个对象中提供实现代码，并将它们提供给客户端代码。

大多数——如果不是全部的话——可以通过接口完成的事情也可以通过继承来完成。接口可以用来代替使用抽象基类的类设计。选择哪种主要取决于个人经历和品味。(当然，有些人会制定非常严格的规则，规定什么时候选择哪个。)

确实存在一些框架(通常与DI容器结合在一起)，它们迫使您使用接口。

接口是一个契约;它保证指定的方法和属性是可用的。它不提供实现，这使得它与提供实现的类不同。

接口是最高级别的抽象，它不向消费者提供实现细节。

接口在语义上几乎等同于纯抽象类(不提供任何实现的类)。在c#、vb.net和其他语言中，类可以有多个接口，但只能有一个基类。因此，接口相对于类(抽象或其他)的一个特定优势是，您可以实现多个接口，但只能从一个类继承。

对于经验丰富的程序员来说，这可能是一个问题，而不是答案，但是……大部分时间我都是和一个小团队一起工作，我们很亲密，彼此很了解。我想知道什么是真正的界面。但我的上一个项目是和一个新团队合作的，规模更大一些。那是一团冬青。一段时间后，我得出结论:我们应该使用界面。

不是作为解决任何技术问题的方法，而是作为一种设计文档，它是代码，它迫使你遵循这个设计，这是很难忽视的，这将使合作更容易100倍。坐在一起设计界面并不是问题。然后你可以单独拆分和实现这些东西。但是如果你遵循接口，那么团队中的其他人就能更清楚地理解类的思想。

所以，我最好的猜测是，接口确实是安排合作的好方法:实现你想要的任何方式，但是接口之外没有任何公共接口，重写接口必须与其他相关人员一起完成。简单的方法来保持代码的顺序和分离常见的东西，你的唯一的东西。

相关文章：

最新信息: