Thanks for this video, very informative. 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. That went straight over my head lol. What I think I have discovered and why some people struggle with getting a sound understanding of the concepts is that maybe its because there is a coding benefit in using abstract classes and interfaces as well as practical advantage.
@@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.
one thing is, if you wanna change the interface like adding new method / property to it, it will break all implementations. And if you make new interface to replace it, you need to document it and educate other devs in the team. It's disaster especially for package / framework devs. So one important rule would be: If you are going to design an interface, design it very carefully and target it to the future.
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.
Given that this would be a great topic for newer developers to understand better, I think the video would benefit from slowing down a little bit (or reducing the scope, if you want to keep it sub 15 minutes). Don't get me wrong, you are saying a lot of really important thing, but even with 5 years of .NET experience, I had a hard time keeping up on everything.
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.
I often inherit an Interface into my Abstract class, then put default implementation into my class. Now, of course, you can do that via default interface implementations, but I don’t recommend doing that, because that’s more of a versioning hack that should be kept in reserve for your Enterprise Architect.
good video, tho i would suggest going/running the code to exarcebate the difference between any 2 approaches. You did show the code, but it's hard to grasp between the 2 without running them
I noticed I could use public, internal, and protected access modifiers in the interface. I couldn't use private though Update: doesn't work when inherited from another project. Insisted on public modifiers but worked when implemented 'explicitly' for protected modifiers regardless
One thing that you don’t mention is that creating generic interfaces let you accomplish some pretty great things, via the IN and OUT keywords, by means of covariance and contravariance. That’s probably beyond the scope of this channel, but it’s a good thing to know if you like know what an expert interviewer might follow up this question with.
Nothing related to coding, but I like the fact you didn't unwrinkle your t-shirt and don't care about the late afternoon sun removing half of your facial expressions at the beginning of your video.
Great video! I have two more points which were not mentioned (I think? Or maybe I also forgot haha) - A class can implement multiple interfaces, but only one abstract class. Also maybe the fact that default interface implementation methods can't act on any dependencies coming from the implementing class, it's essentially a static context.
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?
We need more of these interview tips gems
Thanks for this video, very informative. 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. That went straight over my head lol. What I think I have discovered and why some people struggle with getting a sound understanding of the concepts is that maybe its because there is a coding benefit in using abstract classes and interfaces as well as practical advantage.
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.
Best lighting on the tubes, welcome back!
one thing is, if you wanna change the interface like adding new method / property to it, it will break all implementations. And if you make new interface to replace it, you need to document it and educate other devs in the team. It's disaster especially for package / framework devs. So one important rule would be: If you are going to design an interface, design it very carefully and target it to the future.
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.
Loving this channel
He's back 🎉🎉
Given that this would be a great topic for newer developers to understand better, I think the video would benefit from slowing down a little bit (or reducing the scope, if you want to keep it sub 15 minutes). Don't get me wrong, you are saying a lot of really important thing, but even with 5 years of .NET experience, I had a hard time keeping up on everything.
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.
the thing with youtube is you can just pause rewind and rewatch 15 times if you need
I often inherit an Interface into my Abstract class, then put default implementation into my class. Now, of course, you can do that via default interface implementations, but I don’t recommend doing that, because that’s more of a versioning hack that should be kept in reserve for your Enterprise Architect.
the legend is back
"The Square at that point has schizophrenia "🤣🤣
good video, tho i would suggest going/running the code to exarcebate the difference between any 2 approaches. You did show the code, but it's hard to grasp between the 2 without running them
oh my boi is back
That's a really great explanation. I think the interviewer wanted this from me. 😅
welcome back
I noticed I could use public, internal, and protected access modifiers in the interface. I couldn't use private though
Update: doesn't work when inherited from another project. Insisted on public modifiers but worked when implemented 'explicitly' for protected modifiers regardless
One thing that you don’t mention is that creating generic interfaces let you accomplish some pretty great things, via the IN and OUT keywords, by means of covariance and contravariance. That’s probably beyond the scope of this channel, but it’s a good thing to know if you like know what an expert interviewer might follow up this question with.
Nice lighting😊😅
🎉 nice seeing your FACE in my notifications
Thank you Florian )
what's your ide and what theme were you using in this video?
It's Jetbrains Rider
Abstract Base > Inherit > Implement abstracted target interface... avoids issues with dual inheritance. why not just use virtuals?
Nothing related to coding, but I like the fact you didn't unwrinkle your t-shirt and don't care about the late afternoon sun removing half of your facial expressions at the beginning of your video.
Great video! I have two more points which were not mentioned (I think? Or maybe I also forgot haha) - A class can implement multiple interfaces, but only one abstract class. Also maybe the fact that default interface implementation methods can't act on any dependencies coming from the implementing class, it's essentially a static context.
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?
Hey there! You are missing a "t" on your thumbnail. Welcome back btw!
Oooops! thank you
I like your wall its intresting
I think in C++, you can have multiple inheritance just not Java and C# using abstract classes.
What's the editor?
Rider (Jetbrains)
Idea for content: openiddict-core
Hi, pls create a video to explain for Covariant and contravariant
😎
Mate, Dark theme please.
IS A vs CAN DO
Sir, please explain bit slow. Content not able to reaching.
TOO FUCKING FAST. started out ok but started flying.
first one to watch!
more focused on showing off than teaching.
Thanks for the explanation. I think your voice tone and speaking rhythm could use a bit variety. I lost my attention while watching several times.
slow down man ..u r talking too fast