What good is Explicit Interface Implementation?

[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?

[Nicholas Paldino [.NET/C# MVP]]

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]
- ni**************@exisconsulting.com

"Steve W." <bi********@hotmail.com> wrote in message
news:1e****************************@phx.gbl...

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?

[News VS.NET \( MS ILM \)]

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 [.NET/C# MVP]" <ni**************@exisconsulting.com> wrote
in message news:%2****************@TK2MSFTNGP12.phx.gbl...

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]
- ni**************@exisconsulting.com

"Steve W." <bi********@hotmail.com> wrote in message
news:1e****************************@phx.gbl...

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?

[100]

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

"Steve W." <bi********@hotmail.com> wrote in message
news:1e****************************@phx.gbl...

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?

[Joe Mayo]

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
--
http://www.csharp-station.com

"Steve W." <bi********@hotmail.com> wrote in message
news:1e****************************@phx.gbl...

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

[News VS.NET \( MS ILM \)]

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
"Joe Mayo" <jm***@ddiieessppaammeerrssddiiee.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...

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
--
http://www.csharp-station.com

"Steve W." <bi********@hotmail.com> wrote in message
news:1e****************************@phx.gbl...

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

[100]

Hi Jon,

100 <10*@100.com> wrote:

<snip>

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

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.

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.

[Joe Mayo]

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
--
http://www.csharp-station.com

"News VS.NET ( MS ILM )" <sq**********@hotmail.com> wrote in message
news:Ok*************@TK2MSFTNGP11.phx.gbl...

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
"Joe Mayo" <jm***@ddiieessppaammeerrssddiiee.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...

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
--
http://www.csharp-station.com

"Steve W." <bi********@hotmail.com> wrote in message
news:1e****************************@phx.gbl...

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

[Eric Gunnerson [MS]]

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.
"Jon Skeet" <sk***@pobox.com> wrote in message
news:MP************************@news.microsoft.com ...

"News VS.NET \( MS ILM \)" <sq**********@hotmail.com> wrote:

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

I wouldn't. I believe if you're going to implement an interface, you
just implement it - none of this "Well, I sort of implement it, but
only if you cast to the right thing."

It doesn't actually stop anyone from doing things, it just makes it
harder to do them due to casting which looks strange.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too

[News VS.NET \( MS ILM \)]

Thank you, I don't expect you to post client code, just an example
"Joe Mayo" <jm***@ddiieessppaammeerrssddiiee.com> wrote in message
news:eD*************@TK2MSFTNGP10.phx.gbl...

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
--
http://www.csharp-station.com

"News VS.NET ( MS ILM )" <sq**********@hotmail.com> wrote in message
news:Ok*************@TK2MSFTNGP11.phx.gbl...

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
"Joe Mayo" <jm***@ddiieessppaammeerrssddiiee.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...

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
--
http://www.csharp-station.com

"Steve W." <bi********@hotmail.com> wrote in message
news:1e****************************@phx.gbl...
>
> Other than to resolve the problem that arises when a class
> implements two interfaces with the same method signature,
> what good is it?

[Jon Skeet]

100 <10*@100.com> wrote:

<snip>

Anyway, I believe that the main reason for EII is to make posible to
implement different interfaces, which have methods with the same
prototype.
Agreed. Hopefully that's a very rare event though.
All other usages is just tricks that *might* make the code more clear.

And in my view it makes the code *less* clear. Again, just a matter of
taste.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too

[100]

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

"Steve W." <bi********@hotmail.com> wrote in message
news:1e****************************@phx.gbl...

Many thanks to all responders. It's clearer now, but I do
agree with Jon that being able to ultimately call the
explicitly implemented method through casting is very
obscure. I see that multiple interfaces with the same
method signature needs a solution, but why can't we just
explicitly control the access of the implemented method if
that needs to be done?

Steve W.

-----Original Message-----
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?
.

[Eric Gunnerson [MS]]

"Jon Skeet" <sk***@pobox.com> wrote in message
news:MP************************@news.microsoft.com ...

Eric Gunnerson [MS] <er****@online.microsoft.com> wrote:

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.
But my point is that it still *is* visible to the user, because the
fact that it implements ISerializable is visible.

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.

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