In my previous post, I have explained about one of the first four features of C# 8.0 which has been announced by Microsoft recently.
In this post, I will explain one more future feature which is Default Interface Methods.
This feature will allow interfaces to fully define methods just like abstract classes. However, interfaces will still not be able to declare constructors or fields.
Let us see what it is:
Let us take one example of an interface, like IMessage and it has one method named Message as shown below:
interface IMessage {
void Message();
}
And a class will implement it as below:
Class Test : IMessage
{
}
Now imagine we want to add a new method to the interface, it will result in lots of errors in all the classes which have inherited IMessage interface.
Here comes the new feature which changes some basic functionalities of C# language.
We will create a method with the implementation in the interface. Yes, you read it right, we will be able to write the implementation of the method into the interface as below:
interface IMessage {
void Message();
void MessageAll(IEnumberable<MyClass> myClass){
foreach(var i in myClass)
{
//// Your code
}
}
}
So no need to write newly added method into all the classes which inherit IMessage interface.
It is cool, isn’t it?
One basic question would come in the mind is, what is the difference between this and the abstract class?
They are bit similar but there are some major differences.
One of the difference is:
- The interface can be used for multiple inheritances but Abstract class can not be used
- Interfaces will still not be able to declare constructors or fields.
Some useful points for Default Methods feature:
- “Full abstraction” where we used to have plain interfaces and all classes were forced to have its own implementation. Now we are polluting classes with some default implementation for methods which they don’t even know those exist.
- It also breaks interface segregation principle, if we have to change an interface in future and it should not break all the classes but some of the classes need to have the new method added means, the interface is not granular enough and it’s time to introduce new interface and implement for the required classes.
Java announced almost similar feature with 8.0 version earlier and it is becoming so famous among Java developers and it will soon become famous between .Net developers as well 🙂
Neel Bhatt 
So what’s difference between methods in interfaces and extension methods?
LikeLike
Hey, you can find your answer from this thread by rolfbjarne: https://github.com/dotnet/csharplang/issues/52
Extension methods break polymorphism, I can’t see how you’d implement the following using extension methods:
interface I {
public int GetSomething () { return 0; }
}
class A : I { }
class B : I {
public int GetSomething () { return 1; }
}
class C : I {
public int GetSomething () { return 2; }
}
class Other {
static void PrintSomething (I obj) {
Console.WriteLine (obj.GetSomething ());
}
static void Main () {
PrintSomething (new A ()); // this should print 0
PrintSomething (new B ()); // this should print 1
PrintSomething (new C ()); // this should print 2
}
}
LikeLike
How do you solve the multiple inheritance problems? Interface A implements MethodA and interfaceB also implement methodA(). If class C inherits both InterfaceA and InterfaceB then what will happen? Which implementation will be called when you call methodA from methodC of Class c? One more thought is if this problem is solved by what ever means, then allowing multiple inheritance in class would be a better idea then this. This seems to be just trying to copy JAVA
LikeLike
As per my understanding, the interface needs to be specified if 2 interfaces are inherited in a class. I agree with your point to have multiple inheritances in class.
LikeLiked by 1 person
This seems like a bad idea. No, let me change that. This IS a bad idea. No, let me change that. This is a HORRIBLE idea.
This blurs the line between interfaces and abstract classes for no good reason.
Interfaces are quite clearly, and usefully, purposed to define a contract, not to implement the contract.
If you need a base or default implementation, you should be using an abstract class for this.
And now you’ve got multiple inheritance problems as described above, except they’re even worse. You don’t have to just worry about the same method being implemented in two interfaces, but potentially in an abstract class and an interface. You’ll need explicit calls and explicit definitions to make sure you’re getting the one you want, which means the caller now has to know far too much about what it’s calling.
I fail to see how this satisfies a need that couldn’t already be satisfied in another, better way, such as the Adapter pattern.
Please explain to me why anyone would want this, and why I shouldn’t laugh out loud if I see this code in a code review session and reject it automatically.
LikeLike
The very statement that interfaces solve the problem of multiple inheritance is incorrect. There is a reason why we say that we “inherit” a class and “implement” an interface. In terms of OO, Inheritance enforces a parent child relationship, interfaces does not. A person can “move”. But it doesn’t make sense to derieve a car class from person and override the move behaviour, though it will compile. What makes sense it to have an IMovable interace that both Person and Bird can implement.
So, while interfaces having support for implementation might be a cool thing technically, it will only encourage more design mistakes. Because a majority of developers don’t understand that not everything that compiles and runs is correct.
LikeLike