In C# 8 and later, we have default interface methods, so:
Doesn't it ruin the principle of interface?
When should we use default interface methods instead of base (abstract) class?
In C# 8 and later, we have default interface methods, so:
Doesn't it ruin the principle of interface?
When should we use default interface methods instead of base (abstract) class?
As it is explained in the documentation, there are two primary applications:
Virtual extension methods enable an API author to add methods to an interface in future versions without breaking source or binary compatibility with existing implementations of that interface.
It is thus intended as a means to extend APIs (= a set of interfaces) without having to update all existing implementations (since they need to implement the newly added functions).
The traits pattern allows to extend a class with multiple sets of pre-implemented methods. This is not possible with abstract classes: A given class can only inherit from a single parent class, but from multiple interfaces.
Note that this feature comes with the diamond inheritance problem. Thus, apart from these specific applications, this feature should not be used to replace abstract classes.
Why do we have interfaces?
From a theoretical point of view, both interface implementation and class inheritance solve the same problem: They allow you to define a subtype relationship between types.
So why do we have both in C#? Why do we need interfaces at all? Can't we just define an interface as an abstract class, just as we do, for example, in C++?
The reason for this is the diamond problem: (Image source)
If both
B
andC
implementA.DoSomething()
differently, which implementation shouldD
inherit? That's a hard problem, and the Java as well as the C# designers decided to avoid it by allowing multiple inheritance only for special base types which do not include any implementation. They decided to call these special base types interfaces.So, there is no "principle of interface". Interfaces are just a "tool" to solve a particular problem.
So why do we need default implementations?
Backwards compatibility. You wrote a vastly successful library used by thousands of developers worldwide. Your library contains some interface
I
, and now you decide that you need an extra methodM
on it. The problem is:M
toI
, because that would break existing classes implementingI
(because they don't implementM
), andI
to an abstract base class, because that, as well, would break existing classes implementingI
, and you will lose the ability to do multiple inheritance.So how do default implementations avoid the diamond problem?
By not inheriting those default methods (example inspired by the one in this article, see the full article for some interesting corner cases):
Can't I just use extension methods instead of default interface methods?
Default interface methods are not inherited, but they are still virtual. Now, what does that mean? It means that a class can override the behavior of a default interface method:
You cannot do that with extension methods.