Why is it possible to implement an interface method in base class?

In my project I’ve found a strange situation which seems completely valid in C#, because I have no compilte-time errors.

Simplified example looks like that:

using System;
using System.Collections.Generic;

namespace Test
{

    interface IFoo
    {
        void FooMethod();
    }

    class A
    {
        public void FooMethod()
        {
            Console.WriteLine("implementation");
        }
    }

    class B : A, IFoo
    {
    }

    class Program
    {
        static void Main(string[] args)
        {
            IFoo foo = new B();
            foo.FooMethod();
        }
    }
}

Such code compiles. However, note that A is not IFoo and B doesn’t implement IFoo methods. In my case, by accident (after refactoring), A has the method with the same signature. But why should A know how to implement the FooMethod of the IFoo interface? A even doesn’t know that IFoo exist.

For me having such design is dangerous. Because every time I implement some interface I should check if each method in this interface “interferes” with the base class methods.

If this is “pure C# feature”? What is it called? Am I missing something?

why it is not possible to implement inherited pure virtual method with ‘using’ directive? [duplicate]

Possible Duplicate: Why does C++ not let baseclasses implement a derived class’ inherited interface? #include <iostream> class Interface { public: virtual void yell(void) = 0; }; class Impleme

C++: Derived + Base class implement a single interface?

In C++, is it possible to have a base plus derived class implement a single interface? For example: class Interface { public: virtual void BaseFunction() = 0; virtual void DerivedFunction() = 0; }; cl

Explicitly implement interface of unchangeable base class

To begin, this question is very similar but not the same as How to call an explicitly implemented interface-method on the base class . My problem is that I cannot even add any helper method to the bas

Why class need to implement serializable marker interface for serialization? [duplicate]

This question already has an answer here: Why Java needs Serializable interface? 11 answers Techincally i know why class need to implement serializable . Reason is writeObject method of ObjectO

why the interface cannot have static member method [duplicate]

Possible Duplicate: Why shouldn’t C#(or .NET) allow us to put a static/shared method inside an interface? Why we cannot define static method inside interface?

Why can’t I implement an Interface this way? [duplicate]

Possible Duplicate: Does C# support return type covariance? I’m not sure if I’m just being stupid… If I have an interface: public interface IMoop { object Moop(); } Why can’t I implement it like

Why can’t I use inheritance to implement an interface in C++? [duplicate]

Possible Duplicate: Implementing abstract class members in a parent class Why does C++ not let baseclasses implement a derived class’ inherited interface? Considering these objects: struct A { virtu

Difference between an abstract class and an interface? [duplicate]

Possible Duplicate: Interface vs Base class A class implementing an interface has to implement all the methods of the interface, but if that class is implementing an abstract class is it necessary t

combination of extend abstract class and implement interface [duplicate]

Possible Duplicate: Why does ArrayList have “implements List”? I have gone through several articles Diff b/w I vs AC and questions on SO about when to use an interface vs Abstract Class. When I stum

Implement a pure Virtual function in one of the base doesn’t work in this case [duplicate]

Possible Duplicate: C++: Derived + Base class implement a single interface? I have the following declarations: class iSomething { virtual int getData() const = 0; } class *tManager: public tTheManag



Answers

The key word here is implements. Your base class, although it doesn’t know anything about IFoo the method signature has been declared which implements the method in your interface somewhere in your class hierarchy.

So when you implement IFoo in the derived class, it already has the method signature implemented within the class structure so therefore doesn’t need to implement it again.

If you had this:

interface IFoo
{
  void FooMethod();
}
class A
{
  private void FooMethod(){}
}
class B : A, IFoo
{

}

You need to implement IFoo in this case because the IFoo structure isn’t accessible at the point where it is implemented, and as Mark says. You can implicitly implement the interface by doing IFoo.FooMethod() to ensure that you have an implementation despite having an appropriate method signature already defined in the hierarchy.

To implement an interface, a class needs only to (a) declare that it is implementing that interface (such as your class B does), and (b) provide implementations for all the methods defined in the interface, either directly or indirectly via a base class (such as your class B does).

For each member in the interface, the compiler simply looks for an explicit implementation (if one), then a public implementation (implicit implementation), i.e. a method on the public API that matches the interface signature. In this case, A.FooMethod() looks like a fine match for a public implementation. If B wasn’t happy with that selection, it could either new the method, or use an explicit implementation; the latter would be preferred:

void IFoo.FooMethod() { /* explicit implementation */ }

The feature is called inheritance. And if you don’t like the design, just don’t use it. A lot of people dislike inheritance, so you might, either. The definition of inheritance is, that all the members of the base class are also members of the derived one. So there isn’t any compiler error. Therefore the Derived implements the contract IFoo provides. It’s the base class member, which fulfills this requirement.

The beauty of it is, that you can implement an interface through a base functionality (virtual), which can be overriden if a Derived is expected to behave differently.

Interfaces are not inherited, interfaces are implemented. Thus when you derive a class from an interface, it means

hey interface, you will find a method here which implements the method signiture you have provided.

Since the base class has an implementation of the method, with the same method signiture defined in the interface, there will be no problems.

Even if you write a second interface with including the same method signiture it will still work.

interface IFoo2
{
    void FooMethod();
}

class B : A, IFoo, IFoo2
{
}

B do implement IFOO. B inherits from A so it actually looks like this:

class B : IFoo  //Notice there is no A here. 
{
    public void FooMethod()
    {
        Console.WriteLine("implementation");
    }
}

And it is clear (from the above code) that B is implementing the IFoo and nothing is special.

Section 13.4.4. of the C# specification states:

Interface mapping for a class or struct C locates an implementation for each member of each interface specified in the base class list of C. The implementation of a particular interface member I.M, where I is the interface in which the member M is declared, is determined by examining each class or struct S, starting with C and repeating for each successive base class of C, until a match is located:

So it seems that this is well defined behavior, as the correct implementation of the FooMethod is not found in B, so a search is performed on its base class A where a method with matching signature is found. This is even explicitly pointed out in the same section of the spec:

The members of a base class participate in interface mapping. In the example

interface Interface1
{
void F();
}
class Class1
{
    public void F() {}
    public void G() {}
}
class Class2: Class1, Interface1
{
    new public void G() {}
}

the method F in Class1 is used in Class2’s implementation of Interface1.

You say in a comment,

how likely that the one who wrote implementation of FooMethod in A class which doesn’t implement IFoo actually meant to implement IFoo?

Well, it doesn’t matter what the writer of A thought at the time of A’s creation. It’s the writer of B who must take responsibility for the fact that B both inherits from A AND implements IFoo. It is up to the author of B to think about the consequences of the definition of B.

You also say

In my case by accident (after refactoring) A has the method with the same signature

suggesting that this situation came about after A and B had both been written. In that case, the situation changes: When editing a class which is *inherited from * (such as A), it is the editor’s responsibility to check the effects of the edit on all inheriting classes.

While it is not particularly helpful to speculate as to why the creators of C# did what they did, and while I do not like this particular feature, I suspect part of the reason it works as it does is that there is no other good syntax to specify that an interface should be implemented by an already existing base-class method. Requiring that the derived class must define methods that do nothing but chain to the base-class implementation would seem ugly.

That having been said, I think it would have been cleaner for C# to resolve that general problem (interface methods that chain to other members are ugly) by providing a syntax to explicitly attach an interface member to a class member, than use auto-binding semantics to handle one particular situation but require chaining in a more common situation (implementation of interface by protected virtual method):

protected virtual IFoo_Method(int a, int b, int c) { … }

IFoo.Method(int a, int b, int c) { IFoo_Method(a,b,c); }

While the JITter may be able to figure out that the IFoo_Method call should be in-lined, it really shouldn’t have to. It would seem cleaner to declare that the protected method IFoo_Method should be regarded as the implementation of IFoo.Method.

“But why should A know how to implement the FooMethod of the IFoo interface? A even doesn’t know that IFoo exist.”

A doesn’t need to know about existence of interface IFoo. Its not A’s responsibility to implement FooMethod correctly. Apparently A happened to implement the method which has same signature that of IFoo interface method FooMethod.

Its the responsibility of B to implement FooMethod since it is implementing IFoo interface. But since B is already having a method named FooMethod (inherited from A), it does not need to implement it explicitly. If an inherited method is not doing its job, B can new the method and write its own implementation.