When to Qualify Interface Method Names in an Implementation class

[Kevin Frey]

Consider this simple example:

interface IReader
{
bool Read( );
};

class MyReader : IReader
{
bool Read( ); // or should it be bool IReader.Read( ) ?
};

When I declare the implementation of the Read( ) method, what syntax should
I be using - the interface-qualified method name, or not.

I seem to have found situations where the interface-qualified name was not
permitted (can't remember the exact circumstances). It's a pity because the
interface-qualified names really improve the readability of classes which
implement interfaces.

Can anyone state the rules when the qualification is necessary, and when it
will and won't work?

Thanks

 

[Kevin Frey]

I've done some further reading on the subject, and it is not so much that
the interface-qualified name was not an issue, but how other code referenced
the interface member implementations.

According to the Microsoft documentation, an explicit interface member
implementation (using their terminology) cannot be called from the class
reference directly, only via its interface. So there is an immediate to not
qualify the member functions unless you really have to. Of course this
depends on whether the class is likely to be called on those interface
methods directly, or whether the functions will really only be called via
their interface (and/or whether you *only* want them being called via the
interface).

an issue that the "qualification was

 

[Nick Hounsome]

Consider this simple example:

interface IReader
{
bool Read( );
};

class MyReader : IReader
{
bool Read( ); // or should it be bool IReader.Read( ) ?
};

When I declare the implementation of the Read( ) method, what syntax
should I be using - the interface-qualified method name, or not.

I seem to have found situations where the interface-qualified name was not
permitted (can't remember the exact circumstances). It's a pity because
the interface-qualified names really improve the readability of classes
which implement interfaces.

Not really - when you qualify them like that it is called an explicit
interface member and is not unusable without casting to the interface.

There are 3 'classic' examples:

1) Subject specific naming or implementing 'implementation' interfaces

class MyFile: IDisposable
{
public void Close()
{
// you close files don't you
}

void IDisposable.Dispose()
{
Close();
}
}

using(MyFile f = new MyFile())
{
f.Dispose(); // ERROR
f.Close(); // OK
} // f.Dispose called here automatically

2) Implementing interfaces and typesafe alternatives of the same name

class MyFile : ICloneAble
{
// unhelpfully typed version required by interface
object ICloneable.Clone()
{
// call nice version
return Clone();
}

// nicely typed version
public MyFile Clone()
{
return ...;
}
}

3) implementing multiple interfaces with name clashes

interface I1 { void F(); }
interface I2 { void F(); }
class C : I1,I2
{
void I1.F() { /* do I1 thing */ }
void I2.F() { /* do another thing */ }
}