implement interface explicitly

[Tony Johansson]

Hello!

The only reason I can see interface to be implemented explicitly is when the
a class implement two interface having the same
method signature. In all other cases I can implement interface implicitlly.
Can you agree with me about this statement ?

//Tony

 

[Navaneeth.K.N]

Hi,

I think you are correct.

 

[Göran Andersson]

Hello!

The only reason I can see interface to be implemented explicitly is when the
a class implement two interface having the same
method signature. In all other cases I can implement interface implicitlly.
Can you agree with me about this statement ?

//Tony

You would also implement an interface explicitly if you don't want the
methods to be accessible directly for the method, but only when you are
referencing the method via an interface reference.

 

[Marc Gravell]

is when the a class implement two interface having the same

method signature

It could be any scenario where there are conflicting methods with the
same signature but different name but different meaning (for example,
it could conflict with a method from a base class), or it could be two
interfaces with different signatures that vary only in return-type [so
overloading isn't possible]. The classic example of the latter is
IEnumerable and IEnumerable<T> - two parameterless GetEnumerator()
methods with different signatures.

Or just when you don't want those methods confusing the public API.
For example, IXmlSerializable, ITypedList, IListSource, etc - these
methods are so specialized that only code that cares about them needs
to see them.

Marc

 

[Jon Skeet [C# MVP]]

The only reason I can see interface to be implemented explicitly is when the
a class implement two interface having the same
method signature. In all other cases I can implement interface implicitlly.
Can you agree with me about this statement ?

Not quite. There are times when it *sort of* makes sense to implement
an interface, but not every method is actually supported properly -
they might throw NotImplementedException or something similar, for
example.

By implementing them explicitly, you will discourage a lot of uses of
those methods, guiding the caller to more appropriate ones.

As an example, List<T> implements the nongeneric ICollection interface,
which means it has to implement ICollection.IsSynchronized - but a
List<T> is never synchronized, so it *always* returns false. (Basically
synchronized collections are generally a bad idea, but that's a matter
for a different day.) The point is to steer users away from using
IsSynchronized and SyncRoot.

 

[Adam Benson]

If a base class implements an interface and makes the implementation
virtual, then in an extended hierarchy, it can be a real pain to find
exactly where a call on a method ends up.

interface I
{
void MyMethod();
}

public class Base : I
{

public virtual void MyMethod()
{
...
}
}

And then C inherits from Base, and D inherits from C and so on.

Well if you want to trap a call to MyMethod you can spend ages hunting
around all your classes looking for the most-derived class which overrides
MyMethod. But if you implement explicitly and call a virtual method in your
base class then you always know where to put your break point.

i.e.
public class Base : I
{

public virtual void MyMethod()
{
...
}

void I.MyMethod()
{
this.MyMethod() // It doesn't matter where MyMethod is overridden you
only need to trap here.
}
}

Adam.