Back in Dhaka, New Job
Timesaver: Awesome New C# Property Syntax Shortcut

.NET Basics : Explicit vs Implicit Interface Implementation

Nearly all of us know that we can implement an interface in 2 ways, one is explicit and the other one is implicit. In case of the implicit implementation the interface methods stay public and in explicit implementation the methods stay private in C#. Let me show a simple example

interface ICar
{
   void Start();
}

Now this method can be implemented in two ways, the first one is an example of the implicit implementation

class BMW : ICar
{
    public void Start()
    {
        // write code to start the BMW
    }
}

See the method is public, it can also be protected as well. Now the explicit implementation should look like this

class BMW : ICar
{
    void ICar.Start()
    {
        // write code to start the BMW
    }
}

As you can see there is no public or private keyword present for explicit implementation, and if we try to put a access modifier like public or private then we would get a compiler error. However the C# compiler will make this method private.

Well, except for private and public is there any other significance?

No Virtual

Well yes, there is. An explicit method implementation cannot be virtual. So we cannot override the method implementation in a child class. If we had declared the method virtual in the implicit implementation like the code below then we would have been able to override in a subclass.

public virtual void Start();

So you can see the that if we had a specific implementation of BMW that needed a different way to start then we would be able to override the virtual function and call it.

No direct access for Derived class

Also the derived class cannot call the method directly, we cannot call base.Start() in a child class. We would need to cast it to the interface. So a derived class has to write code like this for explicit implementation.

ICar car = this;
car.Start();

No abstract Implementation

I almost forgot another issue, which is ... we cannot use explicit implementation in an abstract form. If we had defined the class BMW an abstract class we could have left the implementation abstract for a derived class to implement like this

abstract void ICar.Start();

But with explicit implementation we cannot delay the implementation in a later derived class.

Hmm ... when is explicit implementation a must?

Well, lets say we had another interface that has the same method with the same signature and then it could be a problem. Let see this example below

interface IBoat
{
    void Start();
}

Now lets assume we have a amphibian car than can run in both land and water but engine for water and land are different so it would require two different methods to start. Since the implicit implementation can have one method the same name in both cases if IBoat and ICar the same method would be called.

class MyAmphibianCar : ICar, IBoat
{
    public void Start()
    {
        // write code to start the BMW
    }
}

This is a problem since we want to have 2 different code to start the engine. So we would have to go to implicit implementation and write code like this

class BMW : ICar, IBoat
{
    void ICar.Start()
    {
        // write code to start the BMW
    }

    void IBoat.Start()
    {
        // write code to start the BMW
    }
}

Now our problem is solved and we can use two different codes for the two implementations.

When is Explicit Implementation a Problem?

If we use explicitly implement a value type then if we need to access the interface methods then we would have to cast the value type to the interface type which would cause boxing and may hinder performance.

kick it on DotNetKicks.com

Comments

Kumana

Good and simple explanation. Thanks!

Moim Hossain

Last night, I was thinking about explicit and implicit interface implementation stuffs [ I am not married so, usually I don’t find anything important to think at night :P ] , and I have discovered a good example of explicit implementation of any interface- and I decided to put my thoughts here- if somebody find it interesting and useful.
Well, we can consider a simple scenario to get a good idea about the usage. Let consider, you have the following interfaces (I am using the Microsoft implementations as an example, so I think I am safe enough from controversy).

interface IDbConnection
{
String ConnectionString {get; set;}
}
interface IDbCommand
{
IDbConnection Connection { get; set;}
}

Now, if you implement these interfaces by SqlConnection and SqlCommand classes- you will find that your SqlCommand class returning a Connection object of type IDbConnection (though the underlying connection object is a SqlConnection instance). This is not a problem but does not seem to be a good one either. Cause all the clients using SqlCommand need to cast the connection instance to a SqlConnection before using any Sql specific tasks.
Did you notice that the .net base class libraries resolved this problem with a beautiful approach- and that is nothing but using the explicit interface implementation feature.
Here is what they did..

abstract class DbConnection : IDbConnection
{
Public String ConnectionString { get; set;}
}
Abstract class DbCommand : IDbCommand
{
IDbConnection IDbCommand.Connection { get; set; }
public DbConnection Connection { get; set; }
}
Now the Sql Implementation goes like..
public sealed class SqlCommand : DbCommand
{
public SqlConnection Connection { get; set; }
}
See, how nice this implementation is. The Sql specific class SqlCommand now has a SqlConnection instance rather having an IDbConnection. And if you cast the SqlCommand to an IDbCommand than you will get the IDbConnection- fair logical – right?
To me, this is the best usage of explicit interface implementation- cause; there was a time when I was quite unhappy with the problem that a specific class was bound to return an abstract instance. And .NET explicit interface implementation resolved that for me. I love .NET :)

Jeff

Did you mean:

"This is a problem since we want to have 2 different code to start the engine. So we would have to go to *explicit* implementation and write code like this"

instead of:

"This is a problem since we want to have 2 different code to start the engine. So we would have to go to implicit implementation and write code like this"

Since you would need to use explicit implementation to resolve the issue of duplicate method names.

The comments to this entry are closed.