Understanding the lack of static method in Interface in C#

In C# there is no way to define a static method in an interface:

interface IMyClass
{
    void MyMethod();  // this is fine
    static int MyStaticMethod();  // not allowed..
    static int MyOtherStaticMethod() { return 1; } // not allowed either
}

This lack of static method can be painful at times, and on the surface one feels there is no reason why it can’t/shouldn’t be supported by the language. But after ploughing through forum discussions and numerous questions on StackOverflow I start to understand why this is the case.

Practically, this is why having static method on the interface is confusing:

interface IMyClass
{
    static int MyStaticMethod();
}

class MyClassA : IMyClass
{
    static int MyStaticMethod() { return 1; }
}

class MyClassB : IMyClass
{
    static int MyStaticMethod() { return 2; }
}

So what does IMyClass.MyStaticMethod return?

Philosophically, an Interface defines a contract, when dealing with an interface you don’t have to know the implementation details but only what is available on the interface. Static method on the hand, are designed so that you have a well known location for a method/property and don’t need an instance of the object to work with it.

These two concepts are polar opposites, and you can’t mix the two together without breaking polymorphism!

  • need4steed

    You get it wrong, static methods in interface are useful for generic types, shouldn’t be call on a interface per se:

    interface IFace{static void Mtd();}

    void doIt() where T :IFace { T.Mtd();}

    That is cool, and not confusing at all!

  • Gui

    @need4steed:
    Make a method that accept an IEnumerable where T : IFace
    Pass different concrete types in the same array to the method.
    Now you don’t know wich T.Mtd() you should call.

    I got here looking why I could’nt have static interfaces, and now it make sense thanks ;).
    But I think another concept like a kind of TypeInterface would still be usefull.

  • http://www.robwilliamson.com Rob

    I think the concept of a static interface is still useful, and not inconsistent – you can’t do object-based polymorphism with a static interface because static entities do not make references to instances.

    A static function in a normal interface, however, is probably inconvenient – usually you want to be implementation-agnostic when dealing with references to interfaces, so I agree that the following is bad:

    interface IMyClass
    {
    static int MyStaticMethod(); // BAD
    }

    The following should (it isn’t, but it would be nice if it were IMO) be permissible:

    static interface IMyStaticInterface
    {
    int MyStaticMethod(); // static is redundant here.
    }

    Next, to visit the example above:
    IMyStaticInterface.MyStaticMethod(); // Compiler error.

    This would be notionally similar to:
    IMyClass instance = new IMyClass(); // Also compiler error.

    The value of a static interface is the compile-time enforcement of a contract – If I have a suite of static functions that require different implementations, when editing this contract, I can ensure I’ve updated each suite by changing the static interface, pointing the compiler at the resulting code, then working through the compilation errors.