What is the rationale of allowing IInterface.Method() and Method() that implements IInterface?

Question

Here's something I do find confusing in C#: the ability to define Method() and IInterface.Method() in a class that implements IInterface.

Example:

public interface ICustomer
{
    void GetName();
}

public class CustomerBase : ICustomer
{
    public void GetName()
    {
        Console.WriteLine("CustomerBase");
    }

    void ICustomer.GetName()
    {
        Console.WriteLine("ICustomer.CustomerBase.GetName()");
    }
}

Yes, GetName() which is a contract method of ICustomer, can coexist with ICustomer.GetName().

Which method is called when? I run the thing in console:

    var customerBase = new CustomerBase();
    customerBase.GetName();  //this prints CustomerBase
    ((ICustomer)customerBase).GetName(); //this prints ICustomer.CustomerBase.GetName()

So, depending on whether customerBase is cast to interface or not, the output is different.

Not only that, the method signature now affects the method that is being called:

    private void PrintCustomer(ICustomer customer)
    {
        customer.GetName();  //this prints ICustomer.CustomerBase.GetName()
    }

    private void PrintCustomer(CustomerBase customer)
    {
        customer.GetName(); //this prints CustomerBase
    }

This behavior is hugely counter-intuitive to me. So here are the questions for the language lawyer:

When this is introduced in C# spec, and at where?
What is the rationale for this? I can't imagine a valid use case, only potential confusion and extra abilities for the developers to shoot themselves in the foot.

You can't think of a valid use case for changing the result of code depending on the exact derived type of an object? ... In your own words, what do you think is the reason to create derived types? I don't think I'm properly understanding what you find counterintuitive, because that seems much too straightforward. — Karl Knechtel, Oct 15 '21 at 04:18
@KarlKnechtel, we _already_ have mechanism to _change the result of code depending on the exact derived type of an object_ in C#, it's called `virtual override` keywords — Graviton, Oct 15 '21 at 04:29
Does this answer your question? [implicit vs explicit interface implementation](https://stackoverflow.com/questions/598714/implicit-vs-explicit-interface-implementation) — Sinatr, Oct 15 '21 at 04:39
class Foo : ICowboy, IPainter() { public void Draw() {...}} is a canonical example. You are not expected to aim at your foot when the caller used IPainter.Draw(). And can't write two Draw() methods without this syntax. Easy to avoid the ambiguity when designing the interfaces from scratch, not when they were cast in stone a while ago, like they normally are. — Hans Passant, Oct 15 '21 at 06:12
If you don't see a use for this, might I suggest that you ignore it, until such time that you encounter a problem and this is the suggested solution. Not every feature has to be immediately obviously applicable for every programmer. — Damien_The_Unbeliever, Oct 15 '21 at 06:26

score 3 · Accepted Answer · answered Oct 15 '21 at 04:32

So just imagine your class CustomerBase have implemented multiple interfaces like ICustomer, ICustomer1…. and these interfaces have some common methods signatures, let’s say void GetName in your case. In that case how the compiler will determine which method definition is for which interface in your class?

What is the rationale of allowing IInterface.Method() and Method() that implements IInterface?

1 Answers1