C# equivalent of Java 8 Default Methods in Interface

Question

I heard that in Java 8 there is a flexibility of having function definitions in an Interface. I think we can have some default state with this feature in all the classes that are implementing such interface.

So, my question is do we have any such feature in C# as of today? Are there any plans from Microsoft on this regard ?

Answer 1

Update

Default Interface Methods are a planned feature for C# 8.

Original Answer

C# doesn't have this exact feature, but Extension Methods solve the same problems that default methods were introduced to solve in Java.

In order to introduce LINQ-like functional methods to common collections in Java 8, the language designers wanted a way to add methods to interfaces like Iterable<>. After all, the .filter(a -> ...).map(a -> ...) syntax is much easier to read than map(filter(a ->...), a2 -> ...), which is what they'd have had to do if they just added utility methods. However, just adding a method signature to an interface would have been a breaking change because anybody who ever implemented that interface would suddenly have code that doesn't build in Java 8 unless they implemented the new methods. So they developed default implementation methods so that putting new methods on an existing interface wouldn't break existing code.

Years earlier, C# had solved the same problem by introducing Extension Methods. Rather than actually changing the interface itself, an Extension method just makes it easy to use a method (like .Where() and .Select() methods on an IEnumerable<>) defined in a utility class, as if it were actually on the target object.

The constraints put on Extension Methods and Default Implementations make them both very similar in scope. There are some advantages and disadvantages to each, which I won't go into here, but in essence they are just two different approaches to solve the same problem.

As it relates to your specific question: one of the downsides of Extension methods is that (being static) they break some of the best-practices of object-oriented code: it's possible to have naming collisions between them, and you can't override them reliably, for example. So it's usually best to avoid them unless you have a problem that cannot easily be solved in any other way. If you're just hoping to provide a default implementation of a method, you're typically better off using a base class instead, and expecting people to extend your base class.

I think you'd find that most Java experts would say the same thing about Default Implementations in Java. They weren't introduced prior to Java 8 because the prevailing wisdom is that interfaces are there to define what a thing is capable of doing, whereas classes are there to define how those things are done. Of course, you can always find a few smart people who think there's no good reason to have interfaces in the first place. But if you're using interfaces, it's presumably because you see value in defining a contract without providing implementation details. Default Implementations were introduced to solve a very specific backwards-compatibility problem, and if you can avoid that problem in the first place then there's not any really good reason I can see to use them.

Extension methods are at the same time more dangerous and more powerful, so there are some good uses for them outside of the backwards-compatibility problem, but they should still be used sparingly and only when other more object-oriented approaches won't work.

Answer 2

The official language proposal for default interface implementations in C# is documented here:

https://github.com/dotnet/csharplang/blob/master/proposals/default-interface-methods.md

It is currently marked with status of "proposal".

With that said, there are numerous use cases for it which are altogether very strong. At present, it seems very likely to be approved as indicated by Mass Torgerson and Dustin Campbell in the video below. If so, it is almost certainly in line to be released with C#8.

https://channel9.msdn.com/Events/Build/2017/B8104

Around 53:00, the discussion begins and a demo is shown.