实现接口的每个类成员都导出一个语义上类似于VB的声明。NET接口声明被编写，例如:

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

尽管类成员的名称经常与接口成员的名称相匹配，而且类成员通常是public的，但这些都不是必需的。你也可以声明:

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

In which case the class and its derivatives would be allowed to access a class member using the name IFoo_Foo, but the outside world would only be able to access that particular member by casting to IFoo. Such an approach is often good in cases where an interface method will have specified behavior on all implementations, but useful behavior on only some [e.g. the specified behavior for a read-only collection's IList<T>.Add method is to throw NotSupportedException]. Unfortunately, the only proper way to implement the interface in C# is:

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

没那么好。

引用Jeffrey Richter从CLR通过c#编写的 (EIMI的意思是显式接口方法实现)

It is critically important for you to understand some ramifications that exist when using EIMIs. And because of these ramifications, you should try to avoid EIMIs as much as possible. Fortunately, generic interfaces help you avoid EIMIs quite a bit. But there may still be times when you will need to use them (such as implementing two interface methods with the same name and signature). Here are the big problems with EIMIs: There is no documentation explaining how a type specifically implements an EIMI method, and there is no Microsoft Visual Studio IntelliSense support. Value type instances are boxed when cast to an interface. An EIMI cannot be called by a derived type.

如果您使用接口引用，ANY虚链可以在任何派生类上显式地替换为EIMI，并且当这种类型的对象强制转换到接口时，您的虚链将被忽略，并调用显式实现。这根本不是多态性。

EIMIs还可以用于从基本框架接口的实现(如IEnumerable<T>)中隐藏非强类型接口成员，这样你的类就不会直接公开非强类型方法，但在语法上是正确的。

隐式是指通过类上的成员定义接口。显式是指在接口上的类中定义方法。我知道这听起来令人困惑，但我的意思是: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.

我使用显式主要是为了保持实现的简洁，或者当我需要两个实现时。不管怎样，我很少使用它。

我相信有更多的理由使用/不使用explicit，其他人会发布。

请参阅本帖的下一篇文章，了解每一篇文章背后的优秀推理。

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

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

By working directly with the interface, you are not acknowledging, and coupling your code to the underlying implementation. In the event that you already have, say, a public property Name in your code and you want to implement an interface that also has a Name property, doing it explicitly will keep the two separate. Even if they were doing the same thing I'd still delegate the explicit call to the Name property. You never know, you may want to change how Name works for the normal class and how Name, the interface property works later on. If you implement an interface implicitly then your class now exposes new behaviours that might only be relevant to a client of the interface and it means you aren't keeping your classes succinct enough (my opinion).

原因# 1

我倾向于使用显式接口实现，当我不鼓励“编程到实现”(来自设计模式的设计原则)。

例如，在一个基于mvp的web应用程序中:

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

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

现在，另一个类(比如演示者)不太可能依赖于StandardNavigator实现，而更可能依赖于navigator接口(因为实现需要转换为接口才能使用Redirect方法)。

原因# 2

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

类的主接口，供网页开发人员使用;而且 演示者使用的“隐藏”接口，我开发它来处理控件的逻辑

下面是一个简单的例子。这是一个列出客户的组合框控件。在这个例子中，网页开发人员对填充列表不感兴趣;相反，他们只是希望能够通过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; }
}

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

但这不是银炮弹

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

我大多数时候使用显式接口实现。以下是主要原因。

重构更安全

当改变一个接口时，最好是编译器能检查它。这对于隐式实现来说比较困难。

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

Adding a function to an interface, where an existing class that implements this interface already happens to have a method with the same signature as the new one. This can lead to unexpected behavior, and has bitten me hard several times. It's difficult to "see" when debugging because that function is likely not located with the other interface methods in the file (the self-documenting issue mentioned below). Removing a function from an interface. Implicitly implemented methods will be suddenly dead code, but explicitly implemented methods will get caught by compile error. Even if the dead code is good to keep around, I want to be forced to review it and promote it.

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

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

这是自我记录

如果我在一个类中看到'public bool Execute()'，它将需要额外的工作来确定它是接口的一部分。有人可能会评论它，或者把它放在一组其他接口实现中，所有这些都在一个区域或分组评论下，说“实现的ITask”。当然，这只在组头不在屏幕外的情况下才有效。

'bool ITask.Execute()'是清晰且无二义性的。

清晰分离的接口实现

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

当我浏览一个类的代码时，当我遇到显式的接口实现时，我的大脑会切换到“代码契约”模式。通常，这些实现只是简单地转发到其他方法，但有时它们会做额外的状态/参数检查，转换传入参数以更好地匹配内部需求，甚至转换为版本控制目的(即多代接口都转移到公共实现)。

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

相关:Jon的原因2。

等等

加上其他答案中已经提到的优势:

当需要时，根据消除歧义或需要内部接口 不鼓励“为实现编程”(Jon的原因1)

问题

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

值类型，因为这将需要装箱和较低的性能。这不是一个严格的规则，取决于接口和它的使用方式。IComparable吗?隐式。IFormattable吗?可能明确。 具有经常被直接调用的方法的普通系统接口(如IDisposable.Dispose)。

此外，当您确实拥有具体类型并希望调用显式接口方法时，执行强制转换可能会很麻烦。我有两种处理方法:

添加公共对象并将接口方法转发给它们以供实现。在内部工作时，通常发生在更简单的接口上。 (我的首选方法)添加一个公共IMyInterface I {get{返回这个;}}(应该内联)并调用foo.I.InterfaceMethod()。如果有多个接口需要此功能，则将名称扩展到I以外(根据我的经验，我很少有这种需求)。