I've been thinking about static interfaces, and I think they would be really useful for software which uses reflection to identify and assemble components. Currently I find myself having to design around this limitation with unnecessary factories or by enforcing conditions at runtime (like checking for methods and throwing exceptions if they aren't present).
It would be great if the following was possible:
foreach (var type in Assembly.GetExecutingAssembly().GetTypes().Where(t => t is IStaticInterfaceType))
(type as IStaticInterfaceType).StaticMethod();
This could be used for singleton patterns, initialization methods, registration methods, constructor contracts, or any number of other things.
I don't know how much overhead this would introduce, but perhaps this would be possible by making every class have its own corresponding Type. This type would be derived from Type and would implement the static interfaces for the type.
This would allow for much safer use of reflection (which is a brilliant tool for keeping things modular and for reducing code bulk).
James Faix commented
@Ryan Riley - I think the concept of what instance vs static interfaces represent is significantly different enough to warrant separating them. A static interface would be a contract that the type itself must implement, whereas an instance interface is a contract an instance must implement.
I could see the combination working, but since interfaces support multiple inheritance, the inconvenience of separating them might be worth the added conceptual clarity.
Ryan Riley commented
What about just making static members available in interface definitions? Why require a separate type of interface? If you could define both instance and static interface members, you could mix and match rather easily.
James Faix commented
I think more broadly, this and some of the posts linked by Johannes can be labelled as "static polymorphism". Currently static types and members are second-class entities in C# (and .NET as in general as I understand it). The common advice is to avoid static types and members because they can lead to spaghetti code and poor design. Yet, they must be used some of the time; they are an essential part of the language. Static interfaces are needed to allow constructor and operator contracts. A related missing feature is static types as generic type parameters.
Johannes Moersch commented
Here are some other feature requests that are encompassed by static interfaces:
Zachary Patten commented
Static interfacing would completely change how people use generic types. They could be used to have classes inherit from an interface without adding the interface to the class declaration.
public static-interface Algebra<T>
static T QuadraticFormula(T a, T b, T c);
public static class Implementer_double : Algebra<double>
// ... implementation for "QuadraticFormula" method ...
public class SystemSolver<T> where T has Algebra<T>
// solves a system of equations by using "QuadraticEquation" function
// IN MAIN:
SystemSolver<double> systemSolver = new SystemSolver<double>();
The type "double" does not inherit from "Algebra", but because the interface is static, it cannot involve polymorphism (overriding). The static functions within the "static-interface" would have to be added to either the vtable or some table (for runtime handling), but this functionality should be relatively easy to implement.
(1) generic mathematics
(2) clean up many factory/conversion implementations (and other common utilities)
(3) allow developers to easily adapt code form other libraries that cannot be altered
(4) would provide an alternative for achieving multiple inheritance like functionality
(5) would allow even faster generic usage for the OCD optimizers (like me)
And these are just a few reasons I came up with in 2 minutes...
MICROSOFT! ADD THIS FEATURE!!!