100% agree, interfaces on their own don't bring any degree of correctness.

How about using interface Segregation if there are many implementations of the original interface where some of them dont need this new method, I like really small interfaces most of the time and in worst case there are a possibility to use a default implementation of the new method since c# 8.0, if you dont want all implementations of the "god interface" to explode when you add the 78th method. :)

@@jonasgranlund4427 Actually the interfaces should always be "minimal" (as small as possible) to represent a specific contract (as you mentioned the solid principle). If an interface got like more than 20 methods (or even 10, it depends), it could much be a design failure. What I meant is, you need to think carefully about your "contract", like what belong to the interface and what not, method signature and possible demands in the future. Even an interface is minimal, it could still face the problem I mentioned.

@@lw5482 I agree on that and I think that on your first point that if there are many places that implement this interface that need the new method you can add it to the "main interface and if the implementations cant implement it at once there is the possibility to do a default implementation of the new method to not break. But if one or more dont need the new method it makes sense with breaking it ut to its own interface or group it somewhere else where it makes sense. I use both but it is usually atleast 20 to 1 where I use interface compared to abstract class. Happy coding.

In C#8 was introduced default methods for interfaces, so when you are adding new method in interface you can write some default logic to this method and do not break any implementation.

noted, thank you

I agree he really knows his stuff. Relaying that to others might be more difficult.

Way too fast. I watched another video that was talking about the 2, but not why or a good explanation. So I found this one, hoping it would help. Talking fast and jumping around the screen. It's hard to keep up with all of it.

what's the question?

@@RawCoding Just a couple of questions about Abstract Classes compared to Interfaces. You mentioned that an abstract class is when you have a set of things that have a commonality and then you take that commonality and abstract it into an abstract class. Whereas with interfaces you said you want to separate the thing that a component is dependent on or the things that its consuming and this is where the bridge or contract comes in ultimately used to decouple your components into code. Just wodering if you could elaborate on that. I thought it was insightful that i mentioned that a lot of the coding paradigm has more of a readability or design benefit than necessarily any practical benefits, and I think thats where a lot of people get confused. For example to some people they think that when it says an interface is a contract that means just make sure that your classes implement the interface. But as you are designing a system it takes on a much different meaning. So there are levels to understanding and if you have an average understanding of interfaces you really dont understand them at all.

It's Jetbrains Rider

Thank you Florian )

Oooops! thank you

Rider (Jetbrains)

point 1 - was mentioned point 2 - that's wrong, in a static-context members belong to the type (there are no objects, only compile time), default implementation cant be called like: IInterface.DefaultMethod, they have to be called on an object the class for which implements the interface.

@@RawCoding Oh, I see, then I missed that, my bad - For the second point I think I picked a poor wording, I meant that the context is basically the interface and potentially accessing other static contexts, but you can't interact with other dependencies like an abstract class / method can. Like, you can't just supply other dependencies to the interface itself unless you do it through property accessors. Just a minor point I figured might be interesting as well. On a side note, I think that a default implementation can be static as well?