4
I was reading about the new features of C# 8 and came across the Default Interface Implentations, i.e., standard implementations in interfaces.
The code below exemplifies
public interface IBankAccountManager{
void PerformTransaction(decimal amount, string reason);
void PerformDebit(decimal amount, string reason){
PerformTransaction(-1 * amount, $"Debit: {reason}");
}
void PerformCredit(decimal amount, string reason){
PerformTransaction(amount, $"Credit: {reason}");
}
}
As we can see, the method PerformDebit
has, in addition to the contract, a standard implementation, which executes the method PerformTransaction
.
I’m wondering if this doesn’t oppose the basic purpose of an interface, which is to establish a contract, not an implementation.
This type of situation is common in an abstract class, which can either have implementations, or abstract methods, which must be superscripted (override
).
The example would be the implementation below:
public abstract class BankAccountManager
{
void PerformTransaction(decimal amount, string reason) { }
void PerformDebit(decimal amount, string reason)
{
PerformTransaction(-1 * amount, $"Debit: { reason}");
}
void PerformCredit(decimal amount, string reason)
{
PerformTransaction(amount, $"Credit: {reason}");
}
}
Returning to the case of the interface, it seems to me that it escaped a little to the purpose of an interface. I then went to search the literature of OO on this:
https://docs.microsoft.com/pt-BR/dotnet/csharp/programming-guide/interfaces/
An interface contains settings for a feature group related that a class or a struct can implement.
And further down the link:
The interface does not provide any functionality that a class or a struct can inherit in the way that it can inherit the functionality of base class
That is, in the link Microsoft itself contradicts itself on this.
Other references:
An abstract class can contain logic (code), while an interface can only specify which methods or properties (in the case of .NET) a class that implements the interface must define.
And we have the question "In OOP, an interface can have attributes?" em-Oop-a-interface-can-have-attributes
That has the following answers:
1)
An interface is a "purely abstract class", which only specifies a type but does not materialize it.
2)
In general, no. But nothing prevents a language from determining that it can. It would be weird, but it might. She’d probably stop being exactly an interface, even if it kept the name.
The second @Maniero response makes sense, it may not seem right, but there’s nothing saying it can’t be done. No Wiki:
In object-oriented programming, the interface of an object consists of of a set of methods that an object must support.
I saw that in Java, from version 8, also has the Default Methods, which is the same functionality of implementing code in interface.
Even so, two doubts:
Why not use an abstract class instead of a Default Method to implement code in the methods?
What scenario would be useful to implement on the interface and that cannot be done with an abstract class?
In the case of Java, oracle tutorial and the dzone article you linked explain the main use case: extend the functionality of an interface without breaking backcompatibility. In the case of C#, I don’t know if it was created for the same reason, or if it works exactly the same way.
– hkotsubo
Well scored @hkotsubo, is an acceptable reason, on
C#
would be the same scenario, but it seems to me that Versionar would also solve the problem– Ricardo Pontual