Standard implementations in interface with C #

Question

Standard implementations in interface with C #

Navigation

#1 by (4 votes)
#2 by (-2 votes)

4

I was reading about the new features of C # 8 and I came across Default Interface Implentations , that is, 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 PerformDebit method has, in addition to the contract, a default implementation, which executes the PerformTransaction method.

I'm wondering if this does not preclude 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 have both implementations and abstract methods that must be overwritten ( 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 interface case, it seems to me that it has somewhat eluded the purpose of an interface. I was then researching the OO literature about it:

link

An interface contains settings for a group of features related functions that a class or a struct can implement.

And below in link :

The interface does not provide any functionality that a class or a struct can inherit in the way that it can inherit functionality from the base class

That is, in Microsoft link contradicts itself.

Other references:

abstract-class-x-interface

An abstract class can contain logic (code), whereas a interface can only specify which methods or properties (in the case of .NET) a class that implements the interface should define.

And we have the question "In OOP, can an interface have attributes?" in-oop-an-interface-can-have-attributes

You have the following answers:
1)

An interface is a "purely abstract class", which only specifies a type but does not accomplish it.

2)

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

@Maniero's second answer makes sense, it may not seem right, but there's nothing saying it can not be done. In the 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, as of version 8, also has the Default Methods , which is the same functionality as implementing code in the interface .

Still, two doubts:

What scenario would be useful to implement in the interface and which can not be done with an abstract class?

c# interface c#-8

asked by anonymous 07.06.2018 / 18:41

2 answers

-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 sound emission in common. Each emits a type of sound. In addition, the sound will vary according to the occasion.

There is also the fact that they can not gain weight or lose weight indefinitely, otherwise they will 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 common behavior would not instantiate, that is, it would not exist as a living entity.

07.06.2018 / 19:20

As per legend at a point created in an image Separate content from the row in the BufferedReader loop

score 4 · Accepted Answer

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


And below 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 the base class

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

Everything that was said about C # interfaces becomes obsolete in C # 8. As has already happened in Java. That's why I tell people to be careful about 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 it 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 no longer be exactly an interface, even if it retained the name.

In fact, the interface becomes a trait , or almost. It's just a matter of keeping your name so you do not enter a new keyword. It has been created for this .

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

Wikipedia in Portuguese is not very good and because it is a source that is expected to be canonical, it should be more careful. It's almost that, but not 100%. It has a lot of licking 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 do many. This is the main reason for having a new engine.

What scenario would be useful to implement in the interface and what can not be done with an abstract class?

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

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