Default implementations in interfaces
With last week’s posts Announcing .NET Core 3.0 Preview 5 and Visual Studio 2019 version 16.1 Preview 3, the last major feature of C# 8.0 is now available in preview.
A big impediment to software evolution has been the fact that you couldn’t add new members to a public interface. You would break existing implementers of the interface; after all they would have no implementation for the new member!
Default implementations help with that. An interface member can now be specified with a code body, and if an implementing class or struct does not provide an implementation of that member, no error occurs. Instead, the default implementation is used.
Let’s say that we offer the following interface:
interface ILogger
{
void Log(LogLevel level, string message);
}
An existing class, maybe in a different code base with different owners, implements ILogger:
class ConsoleLogger : ILogger
{
public void Log(LogLevel level, string message) { ... }
}
Now we want to add another overload of the Log method to the interface. We can do that without breaking the existing implementation by providing a default implementation – a method body:
interface ILogger
{
void Log(LogLevel level, string message);
void Log(Exception ex) => Log(LogLevel.Error, ex.ToString());
}
The ConsoleLogger still satisfies the contract provided by the interface: if it is converted to the interface and the new Log method is called it will work just fine: the interface’s default implementation is just called:
public static void LogException(ConsoleLogger logger, Exception ex)
{
ILogger ilogger = logger; // Converting to interface
ilogger.Log(ex); // Calling new Log overload
}
Of course an implementing class that does know about the new member is free to implement it in its own way. In that case, the default implementation is just ignored.
The best way to get acquainted with default implementations is the Tutorial: Update interfaces with default interface members in C# 8 on Microsoft Docs.
Happy hacking!
Mads
I am very confused…
They are really going to change a very basic and fundamental concept of OOP!!!!
Why should an interface has default implementation for method?????
In OOP an interface is a contract for class that assigns structure of it.
In fact because of this reason that interface doesn’t have implementation, classes can implement(inherit) from multiple interfaces.
This is very mess....
With this feature SOLID principles are going to die and Abstract class will...
Wow, that give us a chance to broke OCP! And we can use 3rd party classes in interfaces and create more vendor lock. We could even create an integration hell in unit testing with this powerful feature! Also, we could forgot about word ‘contract’ – this term means nothing after this powerful feature. Now we can write shitcode much more easily! Thanks!
what a bunch of nonsense! turning simple things into java/c++/scala syntax crap. You need to stop messing arround with c#. put the VB team in charge and fire those who came up with this useless ideas. you where supposed to be the leaders…not the followers. 😤🤮
It’s a bad mistake….
SOLID principle is going to die…..
What a BS! Nice and beautiful interfaces becoming complete and utter crap. And motivation for this “change” is rather ugly too. I’d fire person (or group of persons) who “invented” this.
UPD: Seems like mind twisted “experts” from C++ committee have joined .NET team.
I don’t like that. It seems over engineering.
Seems like a multiple-inheritance mess waiting to happen.Is this Jon Skeet approved?
Without private methods in interface it has little or no use IMHO, because in this example extension would be sufficient. Pity it is the last major feature — I still wait for types unions and intersections 🙂
Multiple inheritance? Is it you?
Don’t think so.
An interface does not has the ability to maintain states (fields), it can only define behaviors. It’s different from a class.
I have a question about c# grammar, can I try to give feedback? But I can't find a website about the discussion. Let me talk about it directly here?
if (name == null){ throw new ArgumentNullException(nameof(name));}
// Can you develop a grammar like this?name ?? throw new ArgumentNullException(nameof(name));
There may be thousands of such judgments in the project, and then an exception is thrown. Can it be extracted into a single code to do it?
Absolutely.
You can do it with discard.
_ = this.name ?? throw new ArgumentNullException(nameof(name));
This is just plain horrible. It pointlessly blurs the line between interface and abstract base classes. Keep interfaces as simple contracts of functionality and override functionality via derived classes.
It’s a bad mistake….
SOLID principle is going to die