By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,533 Members | 1,497 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,533 IT Pros & Developers. It's quick & easy.

What good is Explicit Interface Implementation?

P: n/a
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?
Nov 15 '05 #1
Share this Question
Share on Google+
12 Replies


P: n/a
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?

Nov 15 '05 #2

P: n/a
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?


Nov 15 '05 #3

P: n/a
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?

Nov 15 '05 #4

P: n/a
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?

Nov 15 '05 #5

P: n/a
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?


Nov 15 '05 #6

P: n/a
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.
Nov 15 '05 #7

P: n/a
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?



Nov 15 '05 #8

P: n/a
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

Nov 15 '05 #9

P: n/a
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?



Nov 15 '05 #10

P: n/a
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
Nov 15 '05 #11

P: n/a
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?
.

Nov 15 '05 #12

P: n/a
"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.
Nov 15 '05 #13

This discussion thread is closed

Replies have been disabled for this discussion.