C# Interfaces. Implicit implementation versus Explicit implementation

Question

What are the differences in implementing interfaces implicitly and explicitly in C#?

When should you use implicit and when should you use explicit?

Are there any pros and/or cons to one or the other?

---

Microsoft's official guidelines (from first edition Framework Design Guidelines) states that using explicit implementations are not recommended, since it gives the code unexpected behaviour.

I think this guideline is very valid in a pre-IoC-time, when you don't pass things around as interfaces.

Could anyone touch on that aspect as well?

Leeland

Yes , explicit interfaces should be avoided and more professional approach would to implement ISP ( Interface segregation principle) here is a detail article on the same codeproject.com/Articles/1000374/… – Ioneionesco

Answer 1

Implicit is when you define your interface via a member on your class. Explicit is when you define methods within your class on the interface. I know that sounds confusing but here is what I mean: IList.CopyTo would be implicitly implemented as:

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

and explicitly as:

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

The difference is that implicit implementation allows you to access the interface through the class you created by casting the interface as that class and as the interface itself. Explicit implementation allows you to access the interface only by casting it as the interface itself.

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

I use explicit primarily to keep the implementation clean, or when I need two implementations. Regardless, I rarely use it.

I am sure there are more reasons to use/not use explicit that others will post.

See the next post in this thread for excellent reasoning behind each.

Concertante

I know this post is old but I found it very useful - one thing to note if it isn't clear because it wasn't to me was that in the example the implicit one has the public keyword...otherwise you will get an error – Chalcedony

Jeffrey Richter's CLR via C# 4 ed ch 13 shows an example where casting's not needed: internal struct SomeValueType : IComparable { private Int32 m_x; public SomeValueType(Int32 x) { m_x = x; } public Int32 CompareTo(SomeValueType other) {...);} Int32 IComparable.CompareTo(Object other) { return CompareTo((SomeValueType) other); } } public static void Main() { SomeValueType v = new SomeValueType(0); Object o = new Object(); Int32 n = v.CompareTo(v); // No boxing n = v.CompareTo(o); // compile-time error } – Belay

Does it make sense in any case to have both implementations, Implicit and Explicit ? – Epicarp

Today I encountered a rare situation which REQUIRED the use of an explicit interface: A class with a field generated by an interface builder that creates the field as private (Xamarin targetting iOS, using iOS storyboard). And an interface where it made sense to expose that field (public readonly). I could have changed the name of the getter in the interface, but the existing name was the most logical name for the object. So instead I did an explicit implementation referring to the private field: UISwitch IScoreRegPlayerViewCell.markerSwitch { get { return markerSwitch; } }. – Curacy

The horrors of programming. Well, nicely debunked! – Endways

@Curacy another situation (rather more common) that requires explicit implementation of at least one interface member is implementing multiple interfaces that have members with the same signature but different return types. This can happen because of interface inheritance, as it does with IEnumerator<T>.Current, IEnumerable<T>.GetEnumerator(), and ISet<T>.Add(T). This is mentioned in another answer. – Conterminous

Another reason (that I can think of) for using explicit implementation over implicit implementation, is when the use of the interface is for some contextual purpose that would otherwise have no bearing on the rest of the class ie. ISerializable which declares GetObjectData, that aside from serialization/deserialization has absolutely no bearing on the rest of the class and need not be publicly accessible. – Huskamp

Answer 2

Implicit definition would be to just add the methods / properties, etc. demanded by the interface directly to the class as public methods.

Explicit definition forces the members to be exposed only when you are working with the interface directly, and not the underlying implementation. This is preferred in most cases.

1. By working directly with the interface, you are not acknowledging, and coupling your code to the underlying implementation.
2. 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.
3. 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).

Castorena

You make some good points here. especially A. i usually pass my classes around as the interface anyways, but i never really thought about it form that perspective. – Concertante

I'm not sure I agree with point C. A Cat object might implement IEatable but Eat() is a basic part of thing. There would be cases where you would want to just call Eat() on a Cat when you are using the 'raw' object rather than through the IEatable interface, no? – Knighthead

I know of some places where Cat is indeed IEatable without objections. – Catanddog

I completely disagree with all of the above, and would say that using explicit interfaces is the recipe of disaster and not OOP or OOD by their definition ( see my answer about polymorphism) – Munition

@Valentin Kuzub: First, I did not find any answer on your behalf on polymorphism. Second, there are many cases where explicit implementaitons are required. From an academic perspective you may have arguments for "OOP" rational. From a well performing code perspective one can not argue the need for this implementation under the correct context. I ran into this the first time I tried to create a loosley coupled N-Tier application. The abiltiy to pass data via interfaces was crucial, however avoiding downcasting and name collision in a factory model prevented true decoupling. – Individuation

See Also: #4103800 – Individuation

A "few" years late to comment, but anyway: If you have the explicit implementation do anything but point to the implicit implementation, it's problematic. Say you have class MyClass : IInterface, where IInterface requires string Name { get; } and you have an instance MyClass my = new MyClass();. With your suggestion, my.Name would return something different than ((IInterface)my).Name, which is a violation of the Liskov Substitution Principle. And this is not just academic, but could turn into a bug that is very hard to find. – Paste

-1 "Explicit definition ... This is preferred in most cases." That's a matter of opinion. I disagree. (I've been doing OO since Xerox Dandelion workstations in early 80s, and in a wide range of languages since then; have been an avid student of OO language design over those decades.) – Curacy

Point 3 is very compelling. "not keeping your classes succinct enough (my opinion)" could be rephrased as "violating the Interface Segregation Principle of SOLID" – Georgena

@Paste explicit interfaces are exactly what enable you to avoid breaking the Liskov Substitution Principle. When IThing.Name is accessed on your class, it can return a value compatible with the concept of IThing even if the public Name property on the concrete class has a different use. – Lesser

What I like about explicit interface implementations is that they can help when refactoring. If the only reason a method is in your class is to implement a particular method on some interface and that method is later removed from that interface, you’d want to get a compilation error in your class. You do if your implementation is explicit, but not if it is implicit. – Lesser

Answer 3

In addition to excellent answers already provided, there are some cases where explicit implementation is REQUIRED for the compiler to be able to figure out what is required. Take a look at IEnumerable<T> as a prime example that will likely come up fairly often.

Here's an example:

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
}

Here, IEnumerable<string> implements IEnumerable, hence we need to too. But hang on, both the generic and the normal version both implement functions with the same method signature (C# ignores return type for this). This is completely legal and fine. How does the compiler resolve which to use? It forces you to only have, at most, one implicit definition, then it can resolve whatever it needs to.

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: The little piece of indirection in the explicit definition for IEnumerable works because inside the function the compiler knows that the actual type of the variable is a StringList, and that's how it resolves the function call. Nifty little fact for implementing some of the layers of abstraction some of the .NET core interfaces seem to have accumulated.

Knot

@Tassadaque: After 2 years, all I can say is "Good question". I have no idea, except perhaps that I copied that code from something I was working on where it was abstract. – Knot

@Tassadaque, you are correct, but I think the point of Matthew Scharley's post above is not lost. – Preferment

Answer 4

Reason #1

I tend to use explicit interface implementation when I want to discourage "programming to an implementation" (Design Principles from Design Patterns).

For example, in an MVP-based web application:

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

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

Now another class (such as a presenter) is less likely to depend on the StandardNavigator implementation and more likely to depend on the INavigator interface (since the implementation would need to be cast to an interface to make use of the Redirect method).

Reason #2

Another reason I might go with an explicit interface implementation would be to keep a class's "default" interface cleaner. For example, if I were developing an ASP.NET server control, I might want two interfaces:

1. The class's primary interface, which is used by web page developers; and
2. A "hidden" interface used by the presenter that I develop to handle the control's logic

A simple example follows. It's a combo box control that lists customers. In this example, the web page developer isn't interested in populating the list; instead, they just want to be able to select a customer by GUID or to obtain the selected customer's GUID. A presenter would populate the box on the first page load, and this presenter is encapsulated by the control.

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; }
}

The presenter populates the data source, and the web page developer never needs to be aware of its existence.

But's It's Not a Silver Cannonball

I wouldn't recommend always employing explicit interface implementations. Those are just two examples where they might be helpful.

Displeasure

Answer 5

To quote Jeffrey Richter from CLR via C#
(EIMI means Explicit Interface Method Implementation)

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.

If you use an interface reference ANY virtual chain can be explicitly replaced with EIMI on any derived class and when an object of such type is cast to the interface, your virtual chain is ignored and the explicit implementation is called. That's anything but polymorphism.

EIMIs can also be used to hide non-strongly typed interface members from basic Framework Interfaces' implementations such as IEnumerable<T> so your class doesn't expose a non strongly typed method directly, but is syntactical correct.

Munition

Re-implementation of interfaces, though legal, is generally dubious at best. Explicit implementations should generally chain to a virtual method either directly, or through wrapping logic which should be binding upon derived classes. While it's certainly possible to use interfaces in ways which are hostile to proper OOP conventions, that doesn't mean they can't be used better. – Ical

@Valentin What EIMI and IEMI stand for? – Craunch

Explicit Interface Method Implementation – Dorothy

Then should IEMI not be IIMI? – Blamable

-1 for "Generally I see Interfaces as Semi (at best) OOP feature, it provides inheritance, but it does not provide real polymorphism." I strongly disagree. Quite to the contrary, interfaces are all about polymorphism and are not primarily about inheritance. They ascribe multiple classifications to a type. Avoid IEMI, when you can, and delegate, as @Ical suggested, when you can't. Do not avoid interfaces. – Adenectomy

"An EIMI cannot be called by a derived type." << WHAT? That's not true. If I explicitly implement an interface on a type, then I derive from that type, I can still cast it to the interface to call the method, exactly as I would have to for the type it's implemented on. So not sure what you're talking about. Even within the derived type, I can simply cast "this" to the interface in question to reach the explicitly implemented method. – Rhizomorphous

EIMI is "explicit interface member implementation." Not all interface members are methods; some are properties. – Conterminous

I came to the googles looking for the answer to point number 1.) "There is no documentation explaining how a type specifically implements an EIMI method, and there is no Microsoft Visual Studio IntelliSense support." And after tireless searching, you are the one with the exact answer in passive information regarding an otherwise unrelated matter... Hahaha, thank you anyhow! As per the topic you all are discussing here, nice comment friend. :) – Stockade

Answer 6

In addition to the other reasons already stated, this is the situation in which a class is implementing two different interfaces that have a property/method with the same name and signature.

/// <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
}

This code compiles and runs OK, but the Title property is shared.

Clearly, we'd want the value of Title returned to depend on whether we were treating Class1 as a Book or a Person. This is when we can use the explicit interface.

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

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

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

Notice that the explicit interface definitions are inferred to be Public - and hence you can't declare them to be public (or otherwise) explicitly.

Note also that you can still have a "shared" version (as shown above), but whilst this is possible, the existence of such a property is questionable. Perhaps it could be used as a default implementation of Title - so that existing code would not have to be modified to cast Class1 to IBook or IPerson.

If you do not define the "shared" (implicit) Title, consumers of Class1 must explicitly cast instances of Class1 to IBook or IPerson first - otherwise the code will not compile.

Once

Answer 7

I use explicit interface implementation most of the time. Here are the main reasons.

Refactoring is safer

When changing an interface, it's better if the compiler can check it. This is harder with implicit implementations.

Two common cases come to mind:

• 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.

It's unfortunate that C# doesn't have a keyword that forces us to mark a method as an implicit implementation, so the compiler could do the extra checks. Virtual methods don't have either of the above problems due to required use of 'override' and 'new'.

Note: for fixed or rarely-changing interfaces (typically from vendor API's), this is not a problem. For my own interfaces, though, I can't predict when/how they will change.

It's self-documenting

If I see 'public bool Execute()' in a class, it's going to take extra work to figure out that it's part of an interface. Somebody will probably have to comment it saying so, or put it in a group of other interface implementations, all under a region or grouping comment saying "implementation of ITask". Of course, that only works if the group header isn't offscreen..

Whereas: 'bool ITask.Execute()' is clear and unambiguous.

Clear separation of interface implementation

I think of interfaces as being more 'public' than public methods because they are crafted to expose just a bit of the surface area of the concrete type. They reduce the type to a capability, a behavior, a set of traits, etc. And in the implementation, I think it's useful to keep this separation.

As I am looking through a class's code, when I come across explicit interface implementations, my brain shifts into "code contract" mode. Often these implementations simply forward to other methods, but sometimes they will do extra state/param checking, conversion of incoming parameters to better match internal requirements, or even translation for versioning purposes (i.e. multiple generations of interfaces all punting down to common implementations).

(I realize that publics are also code contracts, but interfaces are much stronger, especially in an interface-driven codebase where direct use of concrete types is usually a sign of internal-only code.)

Related: Reason 2 above by Jon.

And so on

Plus the advantages already mentioned in other answers here:

• When required, as per disambiguation or needing an internal interface
• Discourages "programming to an implementation" (Reason 1 by Jon)

Problems

It's not all fun and happiness. There are some cases where I stick with implicits:

• Value types, because that will require boxing and lower perf. This isn't a strict rule, and depends on the interface and how it's intended to be used. IComparable? Implicit. IFormattable? Probably explicit.
• Trivial system interfaces that have methods that are frequently called directly (like IDisposable.Dispose).

Also, it can be a pain to do the casting when you do in fact have the concrete type and want to call an explicit interface method. I deal with this in one of two ways:

1. Add publics and have the interface methods forward to them for the implementation. Typically happens with simpler interfaces when working internally.
2. (My preferred method) Add a public IMyInterface I { get { return this; } } (which should get inlined) and call foo.I.InterfaceMethod(). If multiple interfaces that need this ability, expand the name beyond I (in my experience it's rare that I have this need).

Dorothy

Answer 8

If you implement explicitly, you will only be able to reference the interface members through a reference that is of the type of the interface. A reference that is the type of the implementing class will not expose those interface members.

If your implementing class is not public, except for the method used to create the class (which could be a factory or IoC container), and except for the interface methods (of course), then I don't see any advantage to explicitly implementing interfaces.

Otherwise, explicitly implementing interfaces makes sure that references to your concrete implementing class are not used, allowing you to change that implementation at a later time. "Makes sure", I suppose, is the "advantage". A well-factored implementation can accomplish this without explicit implementation.

The disadvantage, in my opinion, is that you will find yourself casting types to/from the interface in the implementation code that does have access to non-public members.

Like many things, the advantage is the disadvantage (and vice-versa). Explicitly implementing interfaces will ensure that your concrete class implementation code is not exposed.

Lapidify

Nice answer, Bill. The other answers were great but you provided some additional objective viewpoints (on top of your opinions) that made it easier for me to grasp. Like most things there are pros and cons with implicit or explicit implementations so you just have to use the best one for your particular scenario or use-case. I'd say those trying to better figure that out will benefit from reading your answer. – Secunderabad

Answer 9

Every class member that implements an interface exports a declaration which is semantically similar to the way VB.NET interface declarations are written, e.g.

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

Although the name of the class member will often match that of the interface member, and the class member will often be public, neither of those things is required. One may also declare:

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 ... }

Not as nice.

Ical

Answer 10

An implicit interface implementation is where you have a method with the same signature of the interface.

An explicit interface implementation is where you explicitly declare which interface the method belongs to.

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: implicit and explicit interface implementations

Vanward

Answer 11

The previous answers explain why implementing an interface explicitly in C# may be preferrable (for mostly formal reasons). However, there is one situation where explicit implementation is mandatory: In order to avoid leaking the encapsulation when the interface is non-public, but the implementing class is 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() { } }

The above leakage is unavoidable because, according to the C# specification, "All interface members implicitly have public access." As a consequence, implicit implementations must also give public access, even if the interface itself is e.g. internal.

Implicit interface implementation in C# is a great convenience. In practice, many programmers use it all the time/everywhere without further consideration. This leads to messy type surfaces at best and leaked encapsulation at worst. Other languages, such as F#, don't even allow it.

Lasso

Answer 12

One important use of explicit interface implementation is when in need to implement interfaces with mixed visibility.

The problem and solution are well explained in the article C# Internal Interface.

For example, if you want to protect leakage of objects between application layers, this technique allows you to specify different visibility of members that could cause the leakage.

Broach

Answer 13

I've found myself using explicit implementations more often recently, for the following practical reasons:

• 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

Bingham