+1  A: 

In this case, all three classes implement the interface (directly or indirectly). This is because MyAbstractClass1 implements MyInterface, and since MyConcreteClass1 derives from MyAbstractClass1, it also follows that you can treat MyConcreteClass1 as a MyInterface. MyConcreteClass2 can be treated with something that derives from MyAbstractClass1, as long as you treat it as a MyInterface. the derivation from MyInterface in ConcreteClass3 is a bit redundant since MyAbstractClass1 already implements MyInterface.

With all of that information, i'd say that yes, it is redundant to implement MyInterface on MyConcreteClass3 since it derives from MyAbstractClass1 which already implements MyInterface. I think the reason that you cant have an abstract implementation of an interface method is that it provides no code itself and you cannot guarantee that it will be overriden in subcalsses. Use Virtual instead.

RCIX
Why did i get a downvote?
RCIX
"Hold on" is a bad answer...
McWafflestix
There, is that better?
RCIX
+3  A: 

Does ConcreteClass1 also implicitly implement MyInterface because it derives from MyAbstractClass1?

Yes.

ConcreteClass1 should not have to be cast to a MyInterface to access the MyInteface methods right?

Correct. (myConcreteClass1 is MyInterface) will evaluate true.

MyAbstractClass1 can implicitly implement a method of MyInterface as an abstract method, but can't explicitly implement a method of MyInterface as an abstract method.

Explicit implementation is to distinguish between overlapping member signatures. The explicit implementation is private to the class you are implementing it on, so it is not accessible to derived classes (and thus cannot be abstract). You also cannot force classes which derive from MyAbstractClass1 to explicitly implement MyInterface, so there is no way to ensure the abstract member will ever be implemented.

Is MyConcreteClass3 excessive because it's implementing an interface that is already implemented by its base class? Would there be a reason you would want to do that even if you knew all classes that derive from MyAbstractClass1 should also implement MyInterface.

Not necessarily, If you need to explicitly implement a member of the interface to distinguish it from an overlapping member on MyConcreteClass3. Otherwise it is unnecessary.

Rex M
"The explicit implementation is private to the class you are implementing it on": Actually, it's even more private than that, because you can't access it directly. You must cast to the interface first. And makes it somewhat public because anyone can access it through the interface as well. Really weird, but still a nice feature.
Martinho Fernandes
+1  A: 

It's not redundant. Consider this class setup to simplify ...

public interface I
{
    void A();
}

public abstract class B : I
{
    public void A( )
    {
        Console.WriteLine("Base");
    }
}

public class D : B
{
    public void A()
    {
        Console.WriteLine("Hide");
    }
}

public class U
{
    public void M(I i)
    {
        Console.WriteLine("M!");
    }
}

Executing this ...

var d = new D();
var i = (I)d;
var u = new U();

i.A();
d.A();
u.M(d);
u.M(i);

You will get ...

Base
Hide
M!
M!

If you add the interface from the derived class ...

public class D : B, I
{
  public void A()
  {
    Console.WriteLine("Hide");
  }
}

You will get ...

Hide
Hide
M!
M!

So, it effects which implementation of the interface method you get when you get the Iness of your derived class.

JP Alioto