Yan Cui
I help clients go faster for less using serverless technologies.
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!
Whenever you’re ready, here are 3 ways I can help you:
- Production-Ready Serverless: Join 20+ AWS Heroes & Community Builders and 1000+ other students in levelling up your serverless game. This is your one-stop shop to level up your serverless skills quickly.
- Do you want to know how to test serverless architectures with a fast dev & test loop? Check out my latest course, Testing Serverless Architectures and learn the smart way to test serverless.
- I help clients launch product ideas, improve their development processes and upskill their teams. If you’d like to work together, then let’s get in touch.
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!
@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.
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.
interface messenger
{
void static string init1 => “designdata1”
void static string init2 => “designdata2”
void static send(string msg)
}
thread class messenger : messenger { void static send (string msg) { implementation }}
or
domain class messenger
network class messenger
internet class messenger
interface
test class messenger : messenger { void static send(string msg) { (send(designdata}}
(test being some type of def vaiable switch (can be on or off on runtime and design time)
thread, domain network internet mean the static class scope (singleton scope)
test is what is being used when testing (test mode on)
static properties would be directly assignable by calling StaticClass { prop = value , prop2 = value2}
this would eliminate the need for ugly need of object wrapping gateway method in static class…
promote static class over singleton and/or dependency injection
static usage:
Messenger { init1 = “new1”, init2 = “new2” }
Messenger.Send(“msg”);
:test
assert Messenger.Send(“msg”) == true;
Assert…
sorry add bool instead of void as return value to signal return
:test
assert messenger.send(“@baddata@”) == ex
or
assert messenger.send(“@baddata@”) == TException
:test
mock new keyboard.get() { “mockdata” }
.get(true) { “mockdata2” }
messenger { input = keyboard }
assert messenger.sendinput() == true
assert messenger.sendinput(true) == false
anyway i could even clean that up again but clearly there is many things that can be improved in a language like c#