Standard implementations in C#interface

Asked

Viewed 220 times

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:

class-abstract-x-interface

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.

  • 1

    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

2 answers

4


An interface contains definitions for a group of related functionalities that a class or struct can implement.

And further down the link:

The interface provides no functionality that a class or struct can inherit in the way that it can inherit the functionality of the base class

Obviously this definition will change. This is normal in revisions of even the language specification.

Everything said about C# interfaces becomes obsolete in C# 8. As in Java. That’s why I tell people to be careful what they read. That may have been posted with the best of intentions, be correct when posted, be someone who knows the subject, but time makes it even wrong, without her knowing (or remembering).

In general, no. But nothing prevents a language from determining that it can. It would be strange, but it can. Probably it would cease to be exactly an interface, even if it kept the name.

In fact the interface becomes a trait, or almost. It’s just a matter of keeping the name so as not to enter a new keyword. It was created for it.

In object-oriented programming, the object interface consists of a set of methods that an object must support.

Wikipedia in Portuguese is not very good and because it is a source expected to be canonical, it should be more careful. That’s almost it, but not 100%. There is a lot of lambança in several articles about OOP, even in English, but in Portuguese, it is terrible.

Why not use an abstract class instead of a Default Method to implement code in methods?

Only an abstract class can be inherited. Interfaces can many. This is the main reason for having a new mechanism.

What scenario would be useful to implement on the interface and that cannot be done with an abstract class?

This one I just quoted. It also helps to give a slightly better semantics of intention.

What will open of useful, and that the abstract class already allowed, but with the limitation of being only an inherited, is that you can add a new method to the contract and not break the application because now all types that implement that interface have no implementation of that method. The new way of using interface allows you to provide the implementation and then all types of its implementers already gain the behavior "for free", being able to superimpose it, of course. It will even facilitate some design standards, such as the Adapter, for example.

  • 'The new way of using interface allows you to provide the implementation and then all types of implementers already gain the behavior "for free"'. Good point, we just need to be on our toes so we don’t misuse it. In the examples we talked about, we can implement a logic to call a legacy method, to even convert some value to maintain compatibility, etc. I understand that this helps a lot, but the problem is to put a lot of logic in the method and run away from the purpose

  • Of course, this can happen anywhere and depends on the programmer. Someone can for example write 5thousand lines in a method, and not be on the interface. As every resource has to be used carefully.

  • 1

    Exact, abuse and make wrong always might, it is not this new feature that will allow.

-2

Classic:

public interface IAnimal
{
    double Peso { get; }
    double MaiorEstatura { get; }
    double Engorda(double ganhoDePeso);
    double Emagrece(double perdaDePeso);
    string EmissaoTipicaDeSom();
    bool EstaVivo { get; }
}

Animals have no common sound emission. Each emits a type of sound. Moreover, the sound varies according to the occasion.

There is also the fact that they cannot fatten or lose weight indefinitely, otherwise they die.

Some basic behavior would be common among different categories of living beings, and this could be described (implemented) using an abstract class or not. The advantage of using an abstract class is that this ordinary behavior would not instantiate, i.e., it would not exist as a living entity.

  • 2

    Marcelo, I understood the example in relation to implementing an abstract class, but I did not understand the relation of this example with the doubts of default implementation.

  • To default implementation is only played by Microsoft not to lag behind before the initiatives of Android (Java) and iOS (Swift et alli).

Browser other questions tagged

You are not signed in. Login or sign up in order to post.