17

For the record, I've already seen this connect item but I can't really understand what would be the problem in supporting this.

Say I have the following code:

public interface IInterface
{
    void Method();
}

public class Base : IInterface
{
    virtual void IInterface.Method()
    {
        throw new NotImplementedException();
    }
}

what is the problem with the virtual identifier? Having a virtual modifier would make it possible to override indicating there's a different implementation in the base class. I can make it work now by removing the virtual method and creating the derived class like this:

public class Derived : IInterface
{
    void IInterface.Method()
    {
        throw new NotImplementedException();
    }
}

however this way I've really no indication at all that I'm overriding something.

Update:
According to the C# (part: 20.4.1 Explicit interface member implementations) spec there are 2 reasons.

  1. Hiding of certain methods (which I'm using it for).
  2. Having 2 functions with the same signature but different return types (usefull for IClonable for example).

It doesn't say anything however about why you can't make these methods virtual.

Update2:
Given the answers I think I should rephrase the real question here. If The above 2 reasons are the reason why explicit implementation of interfaces was made possible in the first place. Why would it be a problem if you make a method virtual.

thekip
  • 3,660
  • 2
  • 21
  • 41

5 Answers5

16

A method implementating interface explicitly has a special visibility scope = you cannot acces it from another method unless you cast "this" to the target interface type. I suppose it was the reason why virtual specifier is not supported - you cannot override method that is not part of the normal object interface (private/protected/public).

This is my workaround:

public class Base : IInterface
{    
   protected virtual void Method()
   {

   }

   void IInterface.Method()    
   {        
       this.Method()
   }
 }


 public class Derived : Base
 {
     protected override void Method()
     {
     }
 }
alexm
  • 6,854
  • 20
  • 24
  • I don't want to have the method on the base type. This way it becomes visible in instances which are not of the `IInterface` type. One benefit of explicit implementation is hiding the method when the class is not accessed through the interface. – thekip Aug 17 '11 at 09:08
  • 2
    if it is declared "protected" only derived classes will see it. So you have both private interface implementation and extensibility for derived classes – alexm Aug 17 '11 at 09:10
  • 3
    All classes derived from "Base" are of IInterface type, you can only replace the implementation. – alexm Aug 17 '11 at 09:23
  • This is the exact same method in such cases to use which is suggested by C# 5.0 in a Nutshell by Albahari's. – Burak Karakuş Jan 07 '16 at 12:39
  • This should be the best answer for the question so far. Change method to "protected virtual void InnerMethod()" may be a better name. – lingtianlan Dec 29 '16 at 17:08
7

however this way I've really no indication at all that I'm overriding something

Well, you do, sort of - you have the fact that it's clearly an explicit interface implementation. That shows it's providing polymorphic behaviour for that method call which is specified on an interface... why does it matter whether the base class also implemented the interface? What difference will it make to you when you read the code?

To me, the main benefit of stating override is to make sure I've really got the right signature - that it matches the thing I'm trying to override. You've already got that benefit with explicit interface implementation, as if you give a non-existent method or the wrong parameters etc, the compiler will already complain.

I can sort of see your point, but I've never found it to be an actual problem.

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • To me it also tells me I might be replacing (if I don't call the base implementation) functionality from the base class. My main 'problem' is that (to me) it's awkward to have an override for a normal method and being unable to do the same thing for an explicit implementation. I would expect this to be implemented the same way. – thekip Aug 17 '11 at 09:06
  • 1
    @thekip: Basically, explicit interface implementation is odd in a number of ways. I would stick to implicit interface implementation unless you really *need* to use explicit interface implementation, or unless you're trying to actively hide a method that shouldn't be called *at all* (e.g. a mutating method on an immutable type). Bear in mind that using explicit interface implementation, your derived class method can't even call the base class method first. – Jon Skeet Aug 17 '11 at 09:20
  • 1
    Well, when I'm overriding an explicit interface method in a derived class I know that my base class also implements this same interface thus I can safely cast my base to `IInterface` and call the base method. The C# spec gives 2 reasons for having explicit implementation available (see question) but I can see no reason why the virtual part is invalid. – thekip Aug 17 '11 at 11:20
  • 2
    @thekip: What do you mean by "cast my base to IInterface"? All you've got is "this", and if you cast *that* reference to `IInterface`, you'll end up calling yourself again. (If you've got a way of calling the base implementation, I'd be interested to see it.) – Jon Skeet Aug 17 '11 at 11:28
  • 1
    Never mind, I see that's another limitation when implementing explicit interfaces. That's probably why there's no need to override (thus specify virtual) too as you can't really override a function but merely replace it completely. – thekip Aug 17 '11 at 11:42
  • @thekip: Exactly. The concept of a virtual explicit implementation doesn't really apply. – Jon Skeet Aug 17 '11 at 11:45
0

Being able to have explicit interface implementations be virtual would be useful in only one scenario: when a derived-class override needs to call the parent-class implementation. Unfortunately, even if explicit interface implementations could be made virtual, there wouldn't be any way for an overriding class to call its parent's implementation absent some new syntax for doing so. VB.net handles this nicely by allowing a method which implements an interface to be declared Protected with a different name from the interface's method. A derived class can thus override the Protected method (using the appropriate name), and that override can call the parent-class version (using the same name).

supercat
  • 77,689
  • 9
  • 166
  • 211
  • It seems to me like you’re saying the explicit interface implementation cannot be `virtual` *because* it cannot be `override` :-p. If the only reason I’m using an explicit interface implementation is to avoid a namespace collision within the current class, it would seem natural to me for it to support `virtual` and `override` like normal methods. So I guess the VB method sounds nice… – binki Jul 01 '14 at 21:46
  • 1
    @binki: IMHO, the VB approach is the "right" one the way .NET works. It allows namespace-collision issues to be resolved, allows child methods to properly chain to their parents without requiring the creation of an interface implementation whose sole purpose is simply to call a virtual method. If .NET allowed a type to both override and shadow a method, or allowed private virtual functions (which could be overridden, but could only be chained to *from within the derived implementation*), some other approaches might be good as well. – supercat Jul 01 '14 at 22:00
-1

I think the reason can be simply shown in following example. Consider this code:

public interface IInterfaceA
{
    void Method();
}

public interface IInterfaceB
{
    void Method();
}

public class Base : IInterfaceA, IInterfaceB
{
    virtual void IInterfaceA.Method()
    {
       ...
    }

    virtual void IInterfaceB.Method()
    {
       ...
    }
}

public class Derived : Base
{
    public override void Method()
    {
        // Will this override IInterfaceA or IInterfaceB implementation???
    }
}

So, in short, if you explicitly implement multiple interfaces with the same method signature your derived classes will not know which base method you want to override.

ephere
  • 147
  • 2
  • 5
  • 1
    So what about - override void IInterfaceA.Method() ..? That would do. Btw. you cannot specify public on explicit interface implementation. It is public by default. – Rashack Apr 05 '13 at 13:07
  • This answer seems to just say “it can’t be done because there’s no syntax for it”. We’re asking *why* there is no support (including the syntax to disambiguate `override`/`base` references) for it, not for a restatement of that (I think). – binki Jul 01 '14 at 21:51
-1

If there is only one interface that is being inherited from, why do you need to do:

public class Base : IInterface
{
    virtual void IInterface.Method()
    {
       throw new NotImplementedException();
    }
}

Why not just go:

public class Base : IInterface
{
   virtual void Method()
   {
      throw new NotImplementedException();
   }
}
Steve
  • 50,173
  • 4
  • 32
  • 41
  • May be its just an sample he has shown to us. If assumed there could be another custom method with Method() as name. – Zenwalker Aug 17 '11 at 08:58
  • 1
    Because the method is only relevant in the context of the interface. There's no need to call the method when you're not handling interface instances. – thekip Aug 17 '11 at 08:59