interface

[Tony Johansson]

Hello!

I just wonder what is the reason for using public in this case

interface ITest
{
void Foo();
}
class Test : ITest
{
public void Foo() {...}
}

but not in this

class Test : ITest
{
void ITest.Foo(){...}
}

//Tony

 

[Family Tree Mike]

Hello!

I just wonder what is the reason for using public in this case

interface ITest
{
void Foo();
}
class Test : ITest
{
public void Foo() {...}
}

but not in this

class Test : ITest
{
void ITest.Foo(){...}
}

//Tony

It just seems to make the second example harder to call. You would need
to do:

Test t = new Test();
((ITest) t).Foo();

rather than t.Foo() directly as in the first method.

 

[Tony Johansson]

Hello!

Another thing that is a major drawback with explicit implementation of an
interface is
that you can't use virtual.

As I can see it is to use explicit implementation of an interface only when
a class or structure
will implement several interface where you have equal signature

Do you agree with me ?

//Tony

 

[Patrice]

As I can see it is to use explicit implementation of an interface only

when a class or structure
will implement several interface where you have equal signature

It can still be usefull if the interface doesn't solve the core problem
(which is and should be likely rare). This way you can use an object and
don't have anything not directly related come in the way and when really
needed you can then use the other interface...

http://blogs.msdn.com/mhop/archive/2006/12/12/implicit-and-explicit-interface-implementations.aspx
shows also an example ("hides" Dispose when Close makes more sense).

 

[Peter Duniho]

Hello!

I just wonder what is the reason for using public in this case

interface ITest
{
void Foo();
}
class Test : ITest
{
public void Foo() {...}
}

but not in this

class Test : ITest
{
void ITest.Foo(){...}
}

It's not entirely clear what you're asking. The literal answer to your
question is "because the C# specification requires 'public' in one, and
prohibits 'public' in the other".

From your later reply it seems you may be looking for an answer to a
different question, one you didn't actually ask. That is, "why does one
implement an interface implicitly rather than explicitly, or vice a versa?"

There are a variety of reasons one might make that choice one way or the
other, but they all come down to the basic difference in behavior
between the two: with implicit implementation, you can use the interface
member without casting to the interface, but with explicit
implementation you must cast to the interface.

IME, one of the more common reasons to use explicit implementation is
when you have a class that implements more than one interface, one of
which has a member that is the same name as a member in the other
interface. Explicit implementation is the only way to allow the
ambiguity to be resolved.

For example, implementing both IEnumerable, and IEnumerable<T>, each of
which has a GetEnumerator() method. Generally, one would implement
IEnumerable<T> implicitly, and IEnumerable explicitly.

Pete

 

[Michael Starberg]

Hello!
As I can see it is to use explicit implementation of an interface only
when a class or structure
will implement several interface where you have equal signature

Do you agree with me ?

//Tony

Hi Tony.

Last time I used explicit implementation was a custom made thread-safe Cache
singleton. It was read from in many places throughout the codebase, but
needed only to load at application startup and modified/reordered in one
single administrative use case.

So I 'hid' the CRUD methods as an explicit interface implementation. The
class stays isolated with no dependencies to other helper or adapter
classes, which is nice when locking is involved. At the same time, all the
application code, that should never miff around with the data, only saw read
methods.

Worked very well.

Regards
- Michael Starberg