What good is Explicit Interface Implementation?

  • Thread starter Thread starter Steve W.
  • Start date Start date
S

Steve W.

I just read the section (and did the exercise) in the C#
Step by Step book that covers Explict Interface
Implementation (where you specify in the method
implementation the specific interface that you are
implementing in the class.

Other than to resolve the problem that arises when a class
implements two interfaces with the same method signature,
what good is it?

The book says that using EII makes the method effectively
private to the class, but the example cited doesn't agree
with the sample program provided. The example says that a
method, once implemented using the "explicit" syntax must
be called using a cast.

IdentifierToken token = new IdentifierToken();
token.Accept(visitor); // won't complile Accept not
accessible

instead...

((IVisitable)token).Accept(visitor); // major tacky

IdentifierToken implements the IVisitable interface (which
includes Accept() ) using the explicit syntax...

IVisitable.Accept(IVisitor visitor) not...
Public Accept(IVisitor visitor)

However the sample program has explicitly implemented
methods, and no cast is used to call them.

So what is EII good for and how does it work?
 
Steve,

Explicit interface implementation is used when you want to implement an
interface but you don't necessarily want to expose those methods on the
interface as part of the class's methods. For example, you might have a
control which needs to filter all windows messages coming into the
application. You would need to implement IMessageFilter for that. With
explicit interface implementation, you can implement the interface, but not
expose the PreProcessMessage method publically on your control (as it really
has no use there). This is where explicit interface implementation comes in
handy.

Hope this helps.
 
Nicholas

Good example and thank you
If you look at what Jon Skeet said ( he does not like it )
how can Mr. Skeet do your good example her without EII

Thanks again.


Nicholas Paldino said:
Steve,

Explicit interface implementation is used when you want to implement an
interface but you don't necessarily want to expose those methods on the
interface as part of the class's methods. For example, you might have a
control which needs to filter all windows messages coming into the
application. You would need to implement IMessageFilter for that. With
explicit interface implementation, you can implement the interface, but not
expose the PreProcessMessage method publically on your control (as it really
has no use there). This is where explicit interface implementation comes in
handy.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Steve W. said:
I just read the section (and did the exercise) in the C#
Step by Step book that covers Explict Interface
Implementation (where you specify in the method
implementation the specific interface that you are
implementing in the class.

Other than to resolve the problem that arises when a class
implements two interfaces with the same method signature,
what good is it?

The book says that using EII makes the method effectively
private to the class, but the example cited doesn't agree
with the sample program provided. The example says that a
method, once implemented using the "explicit" syntax must
be called using a cast.

IdentifierToken token = new IdentifierToken();
token.Accept(visitor); // won't complile Accept not
accessible

instead...

((IVisitable)token).Accept(visitor); // major tacky

IdentifierToken implements the IVisitable interface (which
includes Accept() ) using the explicit syntax...

IVisitable.Accept(IVisitor visitor) not...
Public Accept(IVisitor visitor)

However the sample program has explicitly implemented
methods, and no cast is used to call them.

So what is EII good for and how does it work?
Click to expand...
Click to expand...
 
As an example of when using EII comes handy could be when you want to
implemet typed list class which support IList interface

class MyClass
{
}

class MyList : IList
{
}

You can do that like:

class MyList : IList
{
public int Add(MyClass obj)
{
//save the reference in a list and return the index
}

int IList.Add(object obj)
{
//this will throw execption if the class is added using IList and
the obj is not of MyClass type.
//You can make your own typecheck and throw your own exception
return this.Add((MyClass)obj);
}
}

if you don't do EII the class will expose method
int Add(object obj) which doesn't make sence in typed list class.
MyList has to accept only objects of MyClass

HTH
B\rgds
100
 
I use it every once in a while. In fact, I used it yesterday, because I had
to. The project I'm working on uses Interfaces extensively. We have a lot
of objects that must implement the same set of methods and set apart in
multiple projects. Interfaces help us make all the objects behave themselves
and allow us to avoid circularities caused by cross project composition.

Anyway, yesterday morning I did a Get Latest and found that someone on the
team added a Name property with only a get accessor to Interface IFoo. I
already had a Name property in my type with both get and set accessors, so
the compile died because I was setting my name property, which would not
have otherwise have been detected, potentially causing runtime problems
later. Anyway, the fix was to implement the IFoo.Name property with the get
and no set accessor. Since we assign instantiated objects to variables of
the interface type (rather than casting), the proper method gets called,
preserving the semantic integrity of the operation.

Joe
 
Joe,
Can you please provide us with a small sample of code to illustrate your fix
Please provide before and after code
Thank you for your input
 
Hi Jon,
It still exposes int Add(object obj) - it just hides it very slightly
so that only code looking at it in a certain kind of way can see it.
Click to expand...

Sometimes I have to implement a standard interface just because the
framework needs it.
As in my example I have designed the list to hold *only* MyClass objects. I
have to pass the objects to some library class method, which expects IList,
though. Hiding interface implementation tells the users of my class that
they shouldn't use IList members in normal circumstances. They still can,
though.
Another example is *Control.ControlCollection*. The designer of this class
decided to implement IList (maybe there is some reason to do so) , but
doesn't want to implement IList.Insert method. S/he hid all or part of
IList's methods and added new method *SetChildIndex*. Anyway because the
objects can be cast to IList IList.Insert throws an excpetion. How ever when
I needed to insert a control at index 0 I saw that there is no such a method
exposed by the class. However, I tried to cast the collection to IList, but
I already new that it won't do.

Anyway, I believe that the main reason for EII is to make posible to
implement different interfaces, which have methods with the same prototype.
All other usages is just tricks that *might* make the code more clear.
 
I can't post client code, but here's the scenario.

*** Initial Code

using System;

interface IMyInterface
{
}

class MyBase
{
private string m_name;

public string Name
{
get { return m_name; }
set { m_name = value; }
}
}

class MyClass : MyBase, IMyInterface
{
static void Main()
{
MyClass myCl = new MyClass();
myCl.Run();

Console.WriteLine("myClass.Name: {0}", myCl.Name);
Console.ReadLine();
}

public void Run()
{
this.Name = "Joe";
}
}

Notice that I have a property that is being set on an instance of this
MyClass. For other purposes, MyClass implements IMyInterface.

Now, someone decides to change IMyInterface like this:

*** Intermediate Code

interface IMyInterface
{
string Name
{
get;
}
// plus some other new stuff.
}

class MyClass : MyBase, IMyInterface
{
// other implementation elided for clarity

public void Run()
{
this.Name = "Joe"; // compiler error
}
public string Name
{
get { return "Mayo, Joe"; }
}

Although MyClass implements Name by virtue of inheriting it from MyBase,
IMyInterface specifies other new members that I must include. So, I do a
thorough review of MyClass and make sure that it implements IMyInterface
properly (in VS.NET retype the interface name and press the Tab key),
including the IMyInterface version of Name. This generates a compiler error
on MyClass.Name because it is hiding MyBase.Name and only implements a get.

So, I do an explicit implementation of Name in MyClass that allows me to use
MyClass.Name and IMyInterface name in the proper contexts and preserve the
semantics of my type.

*** Final Code

using System;

interface IMyInterface
{
string Name
{
get;
}
}

class MyBase
{
private string m_name;

public string Name
{
get { return m_name; }
set { m_name = value; }
}
}

class MyClass : MyBase, IMyInterface
{
static void Main()
{
MyClass myCl = new MyClass();
myCl.Run();

IMyInterface myIf = new MyClass();

Console.WriteLine("myCl.Name: {0}", myCl.Name);
Console.WriteLine("myIf.Name: {0}", myIf.Name);
Console.ReadLine();
}

public void Run()
{
this.Name = "Joe";
}

string IMyInterface.Name
{
get { return "Mayo, Joe"; }
}
}

And here's the output:

myCl.Name: Joe
myIf.Name: Mayo, Joe

Joe
 
Jon,

I tend to agree with you for many interfaces. But if the interface is for
something that isn't really the main purpose of the class, you often don't
want to make it visible to the user.

The Serialize function on ISerializable is a good example. I don't want it
cluttering up the user model.

--
Eric Gunnerson

Visit the C# product team at http://www.csharp.net
Eric's blog is at http://blogs.gotdotnet.com/ericgu/

This posting is provided "AS IS" with no warranties, and confers no rights.
 
Anyway, I believe that the main reason for EII is to make posible to
implement different interfaces, which have methods with the same
prototype.
Click to expand...

Agreed. Hopefully that's a very rare event though.
All other usages is just tricks that *might* make the code more clear.
Click to expand...

And in my view it makes the code *less* clear. Again, just a matter of
taste.
 
Hi Steve,
I think that EII exist only for making posible implementing different
interfaces having methods with the same prototype. In this case making more
than one of them visible will lead to ambiguities. Furthermore, if you make
one of them visible the user of your class won't know part of which
interface is the method s/he is calling. Obviously they have different
implementation.

B\rgds
100
 
Jon Skeet said:
But my point is that it still *is* visible to the user, because the
fact that it implements ISerializable is visible.
Click to expand...

True, though when users look through a class to find what methods to call,
they probably don't look at the interfaces it implements. Or at least I
don't.

But it is really a convenience mechanism - it doesn't prevent access, it
just reduces clutter.
It just feels really clunky to me, I'm afraid - although I can see
where it's needed for name collisions.
Click to expand...




--
Eric Gunnerson

Visit the C# product team at http://www.csharp.net
Eric's blog is at http://blogs.gotdotnet.com/ericgu/

This posting is provided "AS IS" with no warranties, and confers no rights.
 
Back
Top