C# 接口。隐式实现与显式实现

Question

在 C# 中隐式和显式实现接口有什么区别？

什么时候应该使用隐式，什么时候应该使用显式？

其中之一有优点和/或缺点吗？

---

Microsoft 的官方指南（来自第一版框架设计指南）指出使用不建议显式实现，因为它会给代码带来意外的行为。

我认为这个指南在 IoC 之前的时期非常有效，当你不将东西作为接口传递时。

有人也可以谈谈这方面吗？

Answer 1

隐式是指您通过类中的成员定义接口。 显式是指您在接口上的类中定义方法。我知道这听起来令人困惑，但这就是我的意思： IList.CopyTo 将隐式实现为：

public void CopyTo(Array array, int index)
{
    throw new NotImplementedException();
}

和显式实现为：

void ICollection.CopyTo(Array array, int index)
{
    throw new NotImplementedException();
}

区别在于隐式实现允许您通过您创建的类访问接口将接口强制转换为该类以及接口本身。显式实现允许您仅通过将其转换为接口本身来访问该接口。

MyClass myClass = new MyClass(); // Declared as concrete class
myclass.CopyTo //invalid with explicit
((IList)myClass).CopyTo //valid with explicit.

我使用显式主要是为了保持实现干净，或者当我需要两个实现时。无论如何，我很少使用它。

我确信其他人会发布更多使用/不使用显式的理由。

请参阅此帖子中的下一篇文章每个背后都有出色的推理。

Answer 2

隐式定义就是将接口所需的方法/属性等直接添加到类中作为公共方法。

显式定义强制仅在您直接使用接口（而不是底层实现）时才公开成员。在大多数情况下这是首选的。

1. 通过直接使用界面，您并不承认，
   并将您的代码耦合到底层实现。
2. 如果您已经拥有公共财产名称，例如
   您的代码并且您想要实现一个也有一个接口
   Name 属性，明确地执行此操作将使两者保持分离。甚至
   如果他们做同样的事情我仍然会委托明确的
   调用 Name 属性。你永远不知道，你可能想要改变
   Name 如何用于普通类以及 Name、接口如何工作
   物业稍后运作。
3. 如果您隐式实现接口，那么您的类现在公开
   可能只与客户相关的新行为
   界面，这意味着你没有保持你的类简洁
   足够了（我的意见）。

Answer 3

除了已经提供的出色答案之外，在某些情况下，需要显式实现，编译器才能弄清楚需要什么。看一下 IEnumerable 作为一个可能经常出现的主要示例。

这是一个示例：

public abstract class StringList : IEnumerable<string>
{
    private string[] _list = new string[] {"foo", "bar", "baz"};

    // ...

    #region IEnumerable<string> Members
    public IEnumerator<string> GetEnumerator()
    {
        foreach (string s in _list)
        { yield return s; }
    }
    #endregion

    #region IEnumerable Members
    IEnumerator IEnumerable.GetEnumerator()
    {
        return this.GetEnumerator();
    }
    #endregion
}

这里， IEnumerable 实现了 IEnumerable，因此我们也需要这样做。但请稍等，通用版本和普通版本都都实现具有相同方法签名的函数（C# 会为此忽略返回类型）。这是完全合法且良好的。编译器如何决定使用哪个？它迫使您最多只有一个隐式定义，然后它就可以解决它需要的任何问题。

IE。

StringList sl = new StringList();

// uses the implicit definition.
IEnumerator<string> enumerableString = sl.GetEnumerator();
// same as above, only a little more explicit.
IEnumerator<string> enumerableString2 = ((IEnumerable<string>)sl).GetEnumerator();
// returns the same as above, but via the explicit definition
IEnumerator enumerableStuff = ((IEnumerable)sl).GetEnumerator();

PS： IEnumerable 显式定义中的一小段间接寻址之所以有效，是因为在函数内部，编译器知道变量的实际类型是 StringList，这就是它解析函数调用的方式。 .NET 核心接口的一些抽象层的实现似乎已经积累了一些有趣的小事实。

Answer 4

原因#1

当我想阻止“编程实现”时，我倾向于使用显式接口实现（设计模式的设计原则）。

例如，在基于 MVP 的网络中application：

public interface INavigator {
    void Redirect(string url);
}

public sealed class StandardNavigator : INavigator {
    void INavigator.Redirect(string url) {
        Response.Redirect(url);
    }
}

现在是另一个类（例如 presenter) 不太可能依赖于 StandardNavigator 实现，而更有可能依赖于 INavigator 接口（因为需要将实现转换为接口才能使用 Redirect 方法） 。

原因#2

我可能采用显式接口实现的另一个原因是保持类的“默认”接口更干净。例如，如果我正在开发 ASP.NET 服务器控件，我可能需要两个接口：

1. 该类的主接口，供网页开发人员使用； 我开发的演示
2. 者使用的“隐藏”界面来处理控件的逻辑

下面是一个简单的示例。它是一个列出客户的组合框控件。在此示例中，网页开发人员对填充列表不感兴趣；而是对填充列表感兴趣。相反，他们只是希望能够通过 GUID 选择客户或获取所选客户的 GUID。演示者将在第一页加载时填充该框，并且该演示者由控件封装。

public sealed class CustomerComboBox : ComboBox, ICustomerComboBox {
    private readonly CustomerComboBoxPresenter presenter;

    public CustomerComboBox() {
        presenter = new CustomerComboBoxPresenter(this);
    }

    protected override void OnLoad() {
        if (!Page.IsPostBack) presenter.HandleFirstLoad();
    }

    // Primary interface used by web page developers
    public Guid ClientId {
        get { return new Guid(SelectedItem.Value); }
        set { SelectedItem.Value = value.ToString(); }
    }

    // "Hidden" interface used by presenter
    IEnumerable<CustomerDto> ICustomerComboBox.DataSource { set; }
}

演示者填充数据源，网页开发人员永远不需要知道它的存在。

但这不是银色炮弹，

我不建议总是使用显式接口实现。这些只是可能有帮助的两个例子。

Answer 5

引用来自 CLR 通过 C# 的 Jeffrey Richter

（EIMI表示E显式I接口M方法I实现）

对您来说至关重要
了解一些后果
使用 EIMI 时存在。并且因为
这些后果，你应该尝试
尽可能避免 EIMI。
幸运的是，通用接口有帮助
你在很大程度上避免了 EIMI。但有
可能仍有时候您需要
使用它们（例如实现两个
同名接口方法
和签名）。这是大
EIMI 的问题：

• 没有文档解释类型具体如何
  实现EIMI方法，并且有
  不是 Microsoft Visual Studio
  IntelliSense 支持。
• 值类型实例在转换到接口时会被装箱。
• 派生类型无法调用 EIMI。

如果您使用接口引用，则任何虚拟链都可以在任何派生类上显式替换为 EIMI，并且当此类类型的对象转换为接口时，您的虚拟链将被忽略并调用显式实现。这绝不是多态性。

EIMI 还可用于从基本框架接口的实现（例如 IEnumerable）中隐藏非强类型接口成员。因此您的类不会直接公开非强类型方法，但语法正确。

Answer 6

我大部分时间都使用显式接口实现。以下是主要原因。

重构更安全

当更改接口时，如果编译器能够检查它，那就更好了。对于隐式实现来说，这更加困难。

我想到了两种常见的情况：

• 将函数添加到接口，其中实现该接口的现有类恰好具有与新类具有相同签名的方法。这可能会导致意想不到的行为，并且已经让我好几次了。调试时很难“看到”，因为该函数可能未与文件中的其他接口方法一起定位（下面提到的自记录问题）。

• 从接口中删除函数。隐式实现的方法将突然成为死代码，但显式实现的方法将被编译错误捕获。即使死代码很好保留，我也想被迫对其进行审查并推广它。

不幸的是，C# 没有关键字强制我们将方法标记为隐式实现，因此编译器可以进行额外的检查。由于需要使用“override”和“new”，虚拟方法不存在上述任何一个问题。

注意：对于固定或很少更改的接口（通常来自供应商 API），这不是问题。但对于我自己的界面，我无法预测它们何时/如何改变。

它是自记录的

如果我在类中看到“public bool Execute()”，则需要额外的工作才能确定它是接口的一部分。有人可能不得不这样评论它，或者将它放在一组其他接口实现中，所有这些都在一个区域或分组注释下，并写着“ITask 的实现”。当然，只有当组标题不在屏幕外时才有效。

而：“bool ITask.Execute()”是清晰且明确的。

接口实现的清晰分离

我认为接口比公共方法更“公共”，因为它们被精心设计为仅公开具体类型的一小部分表面区域。他们将类型简化为一种能力、一种行为、一组特征等。在实现中，我认为保持这种分离是有用的。

当我查看类的代码时，当我遇到显式接口实现时，我的大脑就会转变为“代码契约”模式。通常，这些实现只是转发到其他方法，但有时它们会进行额外的状态/参数检查、转换传入参数以更好地匹配内部需求，甚至出于版本控制目的进行翻译（即，多代接口都向下转换为通用实现）。

（我意识到公共也是代码契约，但接口要强大得多，特别是在接口驱动的代码库中，直接使用具体类型通常是仅限内部代码的标志。）

相关：Jon 的上述原因 2。

等等

再加上其他答案中已经提到的优点：

• 需要时，根据消歧或需要内部接口
• 不鼓励“编程实现”（乔恩的原因 1）

问题

这并不全是乐趣和幸福。在某些情况下，我坚持使用隐式：

• 值类型，因为这将需要装箱和较低的性能。这不是严格的规则，取决于接口及其使用方式。我有可比性吗？隐含的。我可以格式化吗？大概是明确的。
• 具有经常直接调用的方法的简单系统接口（如 IDisposable.Dispose）。

此外，当您实际上拥有具体类型并想要调用显式接口方法时，进行转换可能会很痛苦。我通过以下两种方式之一处理这个问题：

1. 添加公共并将接口方法转发给它们以进行实现。在内部工作时，通常会发生在更简单的接口上。
2. （我的首选方法）添加一个 public IMyInterface I { get { return this; } } （应该内联）并调用 foo.I.InterfaceMethod()。如果多个接口需要这种能力，请将名称扩展到 I 之外（根据我的经验，我很少有这种需求）。

Answer 7

除了已经陈述的其他原因之外，在这种情况下，一个类正在实现两个具有相同名称和签名的属性/方法的不同接口。

/// <summary>
/// This is a Book
/// </summary>
interface IBook
{
    string Title { get; }
    string ISBN { get; }
}

/// <summary>
/// This is a Person
/// </summary>
interface IPerson
{
    string Title { get; }
    string Forename { get; }
    string Surname { get; }
}

/// <summary>
/// This is some freaky book-person.
/// </summary>
class Class1 : IBook, IPerson
{
    /// <summary>
    /// This method is shared by both Book and Person
    /// </summary>
    public string Title
    {
        get
        {
            string personTitle = "Mr";
            string bookTitle = "The Hitchhikers Guide to the Galaxy";

            // What do we do here?
            return null;
        }
    }

    #region IPerson Members

    public string Forename
    {
        get { return "Lee"; }
    }

    public string Surname
    {
        get { return "Oades"; }
    }

    #endregion

    #region IBook Members

    public string ISBN
    {
        get { return "1-904048-46-3"; }
    }

    #endregion
}

此代码编译并运行正常，但 Title 属性是共享的。

显然，我们希望返回的 Title 值取决于我们是将 Class1 视为一本书还是一个人。这时我们就可以使用显式接口了。

string IBook.Title
{
    get
    {
        return "The Hitchhikers Guide to the Galaxy";
    }
}

string IPerson.Title
{
    get
    {
        return "Mr";
    }
}

public string Title
{
    get { return "Still shared"; }
}

请注意，显式接口定义被推断为公共 - 因此您不能将它们显式声明为公共（或其他方式）。

另请注意，您仍然可以拥有“共享”版本（如上所示），但虽然这是可能的，但这种属性的存在是值得怀疑的。也许它可以用作 Title 的默认实现 - 这样就不必修改现有代码即可将 Class1 转换为 IBook 或 IPerson。

如果您没有定义“共享”（隐式）标题，则 Class1 的使用者必须首先将 Class1 的实例显式转换为 IBook 或 IPerson - 否则代码将无法编译。

Answer 8

如果显式实现，则只能通过接口类型的引用来引用接口成员。作为实现类类型的引用不会公开这些接口成员。

如果您的实现类不是公共的，除了用于创建该类的方法（可能是工厂或 IoC 容器），除了接口方法（当然），那么我没有看到显式实现接口的任何优势。

否则，显式实现接口可确保不使用对具体实现类的引用，从而允许您稍后更改该实现。我想，“确保”就是“优势”。精心设计的实现无需显式实现即可实现此目的。

在我看来，缺点是您会发现自己在可以访问非公共成员的实现代码中将类型转换为接口或从接口转换类型。

像许多事情一样，优点就是缺点（反之亦然）。显式实现接口将确保您的具体类实现代码不会暴露。

Answer 9

每个实现接口的类成员都会导出一个声明，该声明在语义上与编写 VB.NET 接口声明的方式类似，例如，

Public Overridable Function Foo() As Integer Implements IFoo.Foo

尽管类成员的名称通常与接口成员的名称相匹配，并且类成员通常是公共的，这些都不是必需的。还可以声明：

Protected Overridable Function IFoo_Foo() As Integer Implements IFoo.Foo

在这种情况下，类及其派生类将被允许使用名称 IFoo_Foo 访问类成员，但外部世界只能通过强制转换为 <代码>IFoo。当接口方法在所有实现上都具有指定行为，但仅在某些实现上有用行为时，这种方法通常是很好的[例如，只读的指定行为]集合的 IList.Add 方法是抛出 NotSupportedException]。不幸的是，在 C# 中实现该接口的唯一正确方法是：

int IFoo.Foo() { return IFoo_Foo(); }
protected virtual int IFoo_Foo() { ... real code goes here ... }

不太好。

Answer 10

隐式接口实现是指具有与接口相同签名的方法。

显式接口实现是显式声明该方法属于哪个接口的地方。

interface I1
{
    void implicitExample();
}

interface I2
{
    void explicitExample();
}


class C : I1, I2
{
    void implicitExample()
    {
        Console.WriteLine("I1.implicitExample()");
    }


    void I2.explicitExample()
    {
        Console.WriteLine("I2.explicitExample()");
    }
}

MSDN：隐式和显式接口实现

Answer 11

前面的答案解释了为什么在 C# 中显式实现接口可能是更好的选择（主要出于正式原因）。然而，有一种情况强制显式实现：当接口是非public但实现类是public时，为了避免泄漏封装。

// Given:
internal interface I { void M(); }

// Then explicit implementation correctly observes encapsulation of I:
// Both ((I)CExplicit).M and CExplicit.M are accessible only internally.
public class CExplicit: I { void I.M() { } }

// However, implicit implementation breaks encapsulation of I, because
// ((I)CImplicit).M is only accessible internally, while CImplicit.M is accessible publicly.
public class CImplicit: I { public void M() { } }

上述泄漏是不可避免的，因为根据 C# 规范，“所有接口成员都隐式具有公共访问权限。”因此，隐式实现也必须提供公共访问权限，即使接口本身是内部。

C# 中的隐式接口实现非常方便。在实践中，许多程序员一直/到处都在使用它，而没有进一步考虑。这最多会导致混乱的类型表面，最坏的情况会导致封装泄漏。其他语言，例如 F#，甚至不允许。

Answer 12

显式接口实现的一个重要用途是当需要实现具有混合可见性的接口时。

问题和解决方案在文章 C# 内部接口。

例如，如果您想保护应用程序层之间的对象泄漏，此技术允许您指定可能导致泄漏的成员的不同可见性。

Answer 13

我发现自己最近更频繁地使用显式实现，原因如下实用：

• 从一开始就始终使用显式实现可以防止出现任何命名冲突，其中显式实现无论如何，都需要实施

• 消费者“被迫”使用接口而不是实现（又名不是”编程实现”），当你使用 DI 时，他们应该/必须这样做

• 实现中没有“僵尸”成员 - 从接口声明中删除任何成员如果不从实现中删除，将导致编译器错误

• 自动采用可选参数的默认值以及通用参数的约束 - 无需写两次并保持同步