So in this video, we're going to talk about Question 11, what our default implementations in interfaces,
if I asked you, what are the characteristics of interfaces in C-sharp, you would probably be able
to to them pretty easily.
They can only contain method's properties, indexers and events declarations.
They can't have fields.
The methods declared in the interface can't have implementations.
In other words, there are methods with nobodys.
The methods can be declared abstract or virtual because they are implicitly virtual or its members are
by default public and using, and the other access modifier leads to a compilation error.
They can't have static methods.
This is all perfectly correct.
Or rather, was you.
Prop eight was introduced in 2019 with this version of C-sharp new feature was introduced default implementations
in interfaces.
In short, it means that interfaces can now contain methods we've brought.
Because of that, a couple of other changes must have been introduced to.
For example, methods in the interface can be private now.
An interface can contain fields, etc. If you like me are used to the old interfaces, you are probably
quite surprised.
Now this change goes against everything we knew about interfaces that are an abstraction of our behavior,
or that they only define a contract that a class must fulfill.
When I learned about this challenge, my first thought was So what will be the difference between an
interface and an abstract class now?
It seemed to me and quite correctly, that they will be very similar concepts from now on.
So I was asking myself, why did Microsoft decide to introduce this challenge?
So before we dive into technical details, let's understand why.
I will explain it by showing you an example.
Let's say we develop some library that other people or companies will use will publish it as don't amateur
package.
Let's say this is one of the interfaces we defined in our library, and we expect our customers to provide
their own implementations.
Our library is meant for e-commerce, and this interface defines what functionality should the classes
representing others contain.
We finish our work and we release our library.
The release is a roaring success, and more and more people download the package with Nugget.
It is widely used and highly rated.
One year later, we are almost ready to release version two zero.
There is one problem, though we will try to add console method to the I order interface.
But if we do so and our customers upgrade the version of the library, they will all suddenly see compilation
errors all around the record basis.
The classes they defined to implement the older interface do not provide the implementation of the council
method.
We will force our customers to adjust to this breaking change, and this may not be easy.
Some of them may be stuck with development for days and their business may be impacted by it.
One solution could be to extend the existing interface like this.
We will create a new interface extending the old one.
Our customers can gradually start using it in their code base and everyone is happy.
But there is a problem with this solution as our labor evolves.
We may want to add more and more methods to the older interface.
This will lead to creating new interfaces, and soon it will all become hard to maintain.
No one will wrap their heads around all this work in the application as everyone will see things like
I older, I can celebrate older.
I can celebrate older with delivery delay.
I consider older with delivery, delay and discount, etc. And this is where default implementation
in interfaces can help.
We can add new methods to an existing interface and provide default implementations so we won't break
our customers code if they want to.
They can provide their own implementation, but until then, the default implementation will be used.
Let's see this in code.
As you can see, the delayed delivery by Decommitted has a body which was impossible before C-sharp
eight.
Now let's define a class implementing this interface.
And here it is, as you can see, it doesn't provide the implementation of the delayed delivery by this
method.
Let's see if we can call this method on an object of the custom order glass.
Well, that doesn't compile.
We can't use the default interface implementations on the variables of a concrete type.
We must use it via the interface and now it works fine.
And this implementation will be used.
Of course, if we provide the implementation of this method in the concrete glass, it will be used
instead of the implementation from the interface.
Let's add another glass implementing the AI order interface.
As you can see, I changed the implementation of this method.
Let's see what will be printed to the council.
As you can see, if the loan default implementation is provided, it will be used.
All right.
Since now we can define methods and interfaces.
We may need some other things that typically are used in methods like other private methods that can
enclose some piece of logic.
Static methods to do the same if they don't use another static members of the interface also private
fields.
Let's summarize the topic of default implementations in interfaces.
This feature was added in C Sharp eight.
It's mostly designed to make it easier to add new methods to interfaces without breaking the existing
code.
Also, it makes it possible for C-sharp to work with apps targeting Android written in Java and iOS.
Written in Swift as those languages support similar features, they also enable using something called
traits.
What is beyond this conscious level?
I think some article about them in the resources attached to this lecture are the default implementations
in interfaces was a huge turnout, and it completely altered what was true about interfaces in C-sharp.
This feature received a lot of criticism, and to be honest, I can see why the line between interfaces
and up six classes is very, very now.
In practice, it's hard to provide a default implementation that brings up the value in the resources.
I linked our extensive article pointing out some problems with the default implementations in interfaces.
My recommendation is as follows.
Be aware that something like the default implementation of interfaces exist.
Still, I think it's best if you use interfaces as they were meant to be used before C-sharp eight,
unless you are 100 percent sure you know what you're doing and equally sure that this will bring value
to the application.
During the interview, you can be asked what can be the reason for using different implementations in
interfaces?
Different implementations in interfaces are mostly designed to make it easier to add new methods to
interfaces without breaking the existing code without it.
If we automated one interface and we release it as a public library will force everyone who updates
this library to provide the implementation immediately.
Otherwise, the code will not build.
All right.
That's it about this topic.
Thanks for watching and see you in the next lecture.