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

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

原因# 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页面开发人员永远不需要知道它的存在。

但这不是银炮弹

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

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

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

我发现自己最近更经常地使用显式实现，原因如下:

Always using explicit from the starts prevents having any naming collisions, in which explicit implementation would be required anyways Consumers are "forced" to use the interface instead of the implementation (aka not "programming to an implementation") which they should / must do anyways when you're using DI No "zombie" members in the implementations - removing any member from the interface declaration will result in compiler errors if not removed from the implementation too Default values for optional parameters, as well constraints on generic arguments are automatically adopted - no need to write them twice and keep them in sync

引用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>)中隐藏非强类型接口成员，这样你的类就不会直接公开非强类型方法，但在语法上是正确的。

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

如果实现的类不是公共的，除了用于创建类的方法(可以是工厂或IoC容器)，并且除了接口方法(当然)，那么我认为显式实现接口没有任何好处。

否则，显式实现接口将确保不使用对具体实现类的引用，从而允许您在以后更改该实现。“确保”，我想，是“优势”。一个分解良好的实现可以在没有显式实现的情况下完成这一点。

在我看来，缺点是您会发现自己在实现代码中对接口进行类型转换，而接口可以访问非公共成员。

就像许多事情一样，优势就是劣势(反之亦然)。显式实现接口将确保不会公开具体的类实现代码。