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.
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
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?
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.
