For clarity, this chap's tutorials are second to none. He takes a dry subject like 'abstract' classes, breaks it down, gives easy to follow examples and seems to enjoy conveying information to those less experienced than himself. Tim Corey deserves a cyber standing ovation.
Just to clarify: I have no idea what a 'cyber standing ovation' is as I simply made it up on the spot. An image of grateful theater goers doesn't lend itself to internet usage, true, but I'm sure you get my drift.
Hi Tim, I've been a lead for the past 12 years for 2 to 80 devs teams with tons of junior and mid level developers and I've never been able to explain in an easy and understandable way abstract classes, you nailed it my friend, from now on everytime a dev ask me to explain abstract classes to them I will send them a link to this video and demand from them to donate 5 bucks to your Patreon ;) Thank you man
Also for those that might be curious about the difference between a virtual method and an abstract method: Virtual methods have an implementation and provide the derived classes with **the option** of overriding it. while Abstract methods **do not** provide an implementation and **force** the derived classes to override the method.
Oh my God !! 8 years after school, I for the first time, understand what is an abstract class. And the differences with an interface ! Thank you very much Monsieur Tim Corey
A short video that absolutely nails it! "A truck is not a car." True... but a truck is a vehicle, and so is a car. So your base class would be vehicle and car and truck would be child classes since they have similar properties. A motorcycle is also a vehicle, as is a tractor. And all of them implement similar properties.
Thank you, Tim. If you find that I thank you more than once for the same video, it's because sometimes I watch the same video a lot of times :) (I wish I could learn only by watching the video once)
You are welcome. I am glad they are helpful and I am glad you are using them as reference material. That is how I intend for them to be used - they are visual archives of how to do things in C#. Even I refer to them sometimes.
This video was sufficient enough in the explanation in the sense that I can have that "Oh yeah," moment while working. Thing is you have so many options to do the same thing and everyone will tell you something different on how to implement a solution. Sometimes you just need to be aware of a useful functionality.
I don't know if you still read your comment but man you're a amazing. Thank you very much. Teaching the basic, base, interface cleared up a lot of stuff for abstract classes.
Before this video I thought I understood what an abstract class is and how it works. Now I can certainly say I know way better than I used to. Thank you Tim! Awesome video!
I have taken many classes, and I can certainly say that you are very good at teaching. It is a pleasure to learn. I will certainly be purchasing classes.
Wow you picked a great example to explain this. Also the explanations themselves are super understandable. In just 20 minutes you explained this way better than my teachers did in multiple lessons. It helped me a lot, thank you!!
Once you start talking i get this weird awesome vibe that keeps the whole thing intersting to me. You are a wonderful tutor sir, and we are very grateful for what you're doing!
You're honestly the best Tim!! Your videos have helped me grasp the foundational topics so much, and I just love the way you explain concepts in such a clear and concise manner. Thanks loads!!!
Thanks, I know of the use of words "virtual", "abstract" in C#, but it just started to get messy in my head on what's the actual difference between interface and abstract. Now it's clean for me again!
Thanks for this, I have been reading a book that is heavy on the how and light on the why/when. Your concise explanation helped me to understand the use cases for abstract classes better.
Yep, there are definitely more similarities, but their purposes have not changed. Don't use an interface in place of an abstract class just because it can have default implementations. That will cause you nothing but pain. Default implementations cannot be used on concrete classes, just with variables that use the interface. Also, they aren't designed to act like abstract classes. They are designed to allow us to upgrade interfaces without breaking legacy code.
0:00 - Intro 0:58 - Demo application walk through 3:19 - Creating a base Class 5:53 - Making the base class abstract 8:44 - "Interface portion" in the abstract class. The blend of interface and base class 12:56 - Class inheritance in abstract class 16:00 - When to use abstract class
Clear explanation and presentation on abstract classes. I like the way you bring the practical side more into your videos rather than presenting only theoretical aspects.
Man, this is really great. I swear I have had so much trouble figuring out abstracts, delegates, and interfaces but these 3 videos changed that. I will be purchasing the full versions of your lessons and learning c# here from now on. I like to re write the code on my own to make sure I understand what each line is doing, and then trying to create my own examples after it helps it stick.
This is really good explanation. Whole video is good, later part i liked most. Right we should not use concept because it is there but should be very careful on where it fits perfect specially in case with inheritance as it must maintain Is-a relationship. Thanks Tim!
Thank you for your time and effort, this really helps me getting better, I just have a hard time understanding all the different classes and how to use them all together with interfaces, its a hard topic to be honest (or I am just a slow learner that is possible aswell)
It is a hard topic. It helps if you start using them (even if you don't fully understand them) in demo projects. As you see how they work, you will get a better grasp on them.
@@IAmTimCorey True that, I try to work with them everyday now making small demo's just for fun, it does help me understanding them all better, and I come watch a lot of your tutorials they are really helpful. At this moment I am following a course for C# and we just started with classes and interfaces (& generics). Everyday its going better, its awesome to see myself improve. Thanks again and have a nice day
1. Same as an abstract class, an interface can't be instantiated, so why would I use an abstract class? 2. Same as an abstract class, an interface can have a method with body to share common logic, so why would I use an abstract class? 3. Same as an abstract class, an interface can force you to implement a method declaration as a contract, so why would I use an abstract class? The only difference I see is the virtual keyword, which would allow you to override an already defined method from the base class, which you can't do with an interface, but other than this, I can't point a situation where an abstract class is a winner over an interface from the point of code syntax. The only place where it makes a difference is in the way that we think about them, but coding wise, we can achieve the same result with both of them in 99% percent of cases. What would be that 1% where abstract classes should be used? Maybe I'm not experienced enough but I feel like this question is not answered in your videos.
First, this video was made before default implementations in interfaces was a thing. Second, I think you have a misunderstanding of default implementations in interfaces. Let me talk you through it. Interfaces are just contracts. They say what a class is going to do. You can have multiple interfaces on one class. It isn't about code sharing, it is about being similar in some way. For instance, you can implement IDisposable, which will allow you to use your class with a using statement. There is no code shared and the classes otherwise have no relationship to each other. Abstract classes are about a relationship structure ("is a" relationship). The value of an abstract class is the establishment of the commonality of the structures with potentially shared code. Later on in .NET, they added default implementations for interfaces. This was not to compete with abstract classes or inheritance, and it was not to add multi-inheritance. What it was designed for was the scenario where you had an interface in production. Multiple classes use it. Now imagine you want to add an additional method to the interface. You can't do that without updating all of your existing classes. The solution at the time was to create a new interface. That is inefficient and confusing. So, the solution was to create default implementations. That way, you could add a new method to the interface without breaking the existing implementations by adding a default implementation. However, this is not the same thing as inheritance. For instance, you cannot call that default implementation unless you cast the instance to the specific interface type. So it isn't really usable as inheritance. It is just there to stop applications from breaking when you add to an interface.
Thanks a lot for taking the time to explain this to me. I missed the point of upcasting to the interface if you want to call that method defined there. Otherwise, I feel like C# doesn't make a great job separating this two well enough to help beginners or intermediate programmers. It's very confusing. KUTGW! I really enjoy your channel.
@@IAmTimCorey Please explain this Same as an abstract class, an interface can force you to implement a method declaration as a contract, so why would I use an abstract class?
Great Video Tim !! How do we decide when to use Abstract class and when to use an interface? Also can we achieve Dependency Inversion through Abstract Class?
Good question. In order to use an abstract class, you need to have an "is a" relationship. So a cat is an animal, so CatModel could inherit from AnimalModel (possibly). Inheritance is a lot harder to use than people think. Remember that you can only inherit from one parent so while the promise of code sharing is great, you can't just use it as a mechanism to not write duplicate code. You need to be very careful about that relationship. When it is done right, though, inheritance (which is what Abstract classes are) can be powerful. For most scenarios, though, Interfaces are the better option. You can have multiple, they can be specific to your needs (look at the Interface Segregation Principle), and they don't imply a relationship. Dependency Inversion really doesn't do well with Abstract classes because you are still somewhat dependent on that abstract class. It is better accomplished with Interfaces.
Great presentation as usual. But this video would feel a bit "in there" for someone new to OOP in general. I think a longer video on architecting software, where requirements are discussed first before a design is created, will remove any cobwebs surrounding the use of Base classes vs Abstract classes vs Interfaces. Given your teaching style, it would become a definitive video on this subject on TH-cam.
Thank you so much for taking your time and making all these videos. Appreciate your efforts !!! I would like to know if you are planning to make a video on Reflection ?
It is on the list. I've been avoiding it a bit because it is such an abused topic (reflection is rarely the correct answer) but I'll cover it at some point.
In C# 8, you can now add default implementations to interfaces, which lets you avoid code repetition without using abstract classes. Though it's mostly meant to add methods to an interface without breaking existing classes that implement it.
I wouldn't use them in place of abstract classes, though, because they aren't the same thing. Those methods are only available if you use the interface type, not if you use the concrete type or a different interface type. Default implementation does not replace abstract classes.
Really helpful and awesome for beginners not to struggle, like some of us, later down the road😊! Do you have any “best practices” for designing the sql(or any relational) data structuring? Keep on rocking, C# for life!
@@KrishnaGupta-zl7dt you said if having default implementation of methods i was thinking of sql insert, update, delete. Since it a default craud behavior.
Good video. Sometimes I find it challenging to figure out when to choose "composition over inheritance". You mention interfaces here, and also how not to treat a car as if it were a truck. Perhaps a future video delving into how/when to choose composition over inheritance. For example, instead of having a car and truck inherit from an abstract vehicle class, just have them both implement the IDriveable interface? ... it's probably one of those situations where there's no right/wrong way, so a video looking at the tradeoffs of doing composition vs inheritance might help. BTW, as I write this I see the Composition Over Inheritance wikipedia page has been flagged as "confusing" since 2015.
Thanks for the suggestion. In general, I default to composition because inheritance is really such a small target. However, it does depend on the situation. I agree that it can be very confusing. I'll add the suggestion to my list.
This a great way to showcases the usage of an abstract class, thanks, Tim! I've worked in different companies and we were using C# as one of the development languages, but I didn't see any usage of an abstract class. My question is: Is it necessary to use abstract classes to achieve the best practice?
Youve forgotten to demonstrate hiding case when LoadString doesnt have virtual so developetr would have to use new instead of override. That would add a cherry on top of this pice of cake.
@@IAmTimCorey Tim, one question if I may from your videos I understand that interfaces can have properties and methods (WITHOUT code in them), and abstract classes can have abstract and virtual methods (WITH or WITHOUT code in them), but not properties. Is that correct? Is that another way to differentiate when to use an abstract class and when to use an interface? Thanks.
Probably the SOLID videos. Here is a playlist with them in it: th-cam.com/play/PLLWMQd6PeGY3ob0Ga6vn1czFZfW6e-FLr.html As for what to learn after advanced topics, you need to be practicing what you learned. A LOT. By the time you get to advanced topics in C#, you should probably have 200-300 practice projects (small ones) done that practice the individual topics you learned. You should also have 2-5 larger practice projects completed as well. Projects like the Tournament Tracker or TimCo Retail Manager projects here on this channel. It isn't about having seen a bunch of topics, it is about having actually used those topics in an application to validate that you understand how to use them well.
Hi Tim, I have a question. For initializing objects, we do something like this. class Program { static void Main(string[] args) { var demo = new DemoClass() {iD=1,Name="vinay" }; var demo2 = new DemoClass() { iD = 2, Name = "Vikas" }; var demo3 = new DemoClass { iD = 1, Name = "vinay", Address = "s", number = 3 }; Console.WriteLine(demo3.Address); } } public class DemoClass { public int iD { get; set; } public string Name { get; set; } public int number { get; set; } public string Address { get; set; } } demo2 object is initialized as var demo2 = new DemoClass() { iD = 2, Name = "Vikas" }; But in demo3 object, I dont use () after new DemoClass but still works fine and gives correct results. Am I doing something wrong here or i didn't understand some concept. Thank you for your time.
demo2 and demo3 are the same thing. It is just that demo3 implicitly uses the default constructor while demo2 explicitly states that it is using the default constructor (the one with no parameters).
Hey, Tim! I didn't get the part of writing DataAccess da = new SqliteDataAcces(); instead of SqliteDataAccess da = new SqliteDataAccess(); could you explain again why we do DataAccess da = new SqliteDataAcces(); ? It's about 11:35.
By using the base class, we can change out the implementation (in this case SqliteDataAccess) for any other implementation without needing to change anything else in our code.
@@IAmTimCorey hi Tim following on .....as @PwnUser mentioned ....Would .....SqliteDataAccess da = new SqliteDataAccess(); produce the same implementation (da object) as............ DataAccess da = new SqliteDataAcces() ......if not ...how would it differ ? (thank you)
Great video, Thanks Tim. but what is ur opinion on using the interface IDataAccess for the DataAccess class and then use the DataAccess class as an abstract class ?
Abstract classes are best when the code is similar AND/OR you require a concrete default method to be inherited. Otherwise you should use an interface. Interfaces are awesome because you can do inversion of control with them.
Hi Tim, very instructive and pleasant time I had watching the video. I may also say: as usual... (lol) I'm looking out for how to use abstract classes for a CRUD project using C# and Winform. Your exemple really light me up my candel. Still, because I'm rookie, I need some more tips. Can you tell me where I can find more about how to construct an abstract CRUD class? Regards
I don't have any specific videos on that. Sorry. However, you can watch my videos on the TimCo Retail Manager and Suggestion Site to see how I set up CRUD operations in those videos. Those might help give you some ideas on what you are looking to do. I will say that I don't quite see how you are expecting abstract classes to help you out with CRUD operations. Almost certainly you aren't going to do simple, predictable reads and writes on your tables.
Hi there. I have set myself in a scenario where I'm not entirely sure of which approach of the base class, abstract class or interface would be the most beneficial. Your example is great, however, I may have gone a step further the complexity of what I'm trying to achieve. Now just for fun, I thought it would be fun to write something like a simple game. Nothing flashy, just in the console to play around with the core logic itself. So with the ide to simulate combat between two characters, like the player and a monster. I thought as a player and monster are both a character when you describe the entity. So at first having an abstract class Character which the class Player & Monster inherits seems about right. So that's grate I can put everything that describes a character in the character abstract class and use it as a blueprint. However, the mind wrapping thing began when I started to set up the structure for spells, Equipiable items and different damage types, as I found to that a class can only have one base class. So that pushes me towards Interfaces, which in my eyes are more a light blueprint compared to a base class which can contain logic for inheritance as well. What confuses me is how to set up a logical hierarchy in this scenario.
I've been there. It all comes down to your last sentence. Plan the logic in paper first, and then jump to coding. As Tim says: "plan before you build". I used to make the logic on the fly along with the code and some loosely coupled ideas... trust me, fun becomes a mess in no time.
@@jonatancordoba7984 yes it really helps visualize the concept with a mind map. After some try and error, interfaces seams to be way to connect everything else with character that is not a natural attribute.
For clarity, this chap's tutorials are second to none. He takes a dry subject like 'abstract' classes, breaks it down, gives easy to follow examples and seems to enjoy conveying information to those less experienced than himself. Tim Corey deserves a cyber standing ovation.
Just to clarify: I have no idea what a 'cyber standing ovation' is as I simply made it up on the spot. An image of grateful theater goers doesn't lend itself to internet usage, true, but I'm sure you get my drift.
I appreciate the kind words and the ovation.
Hi Tim, I've been a lead for the past 12 years for 2 to 80 devs teams with tons of junior and mid level developers and I've never been able to explain in an easy and understandable way abstract classes, you nailed it my friend, from now on everytime a dev ask me to explain abstract classes to them I will send them a link to this video and demand from them to donate 5 bucks to your Patreon ;) Thank you man
I am glad it was so clear and thanks for the recommendations.
Also for those that might be curious about the difference between a virtual method and an abstract method:
Virtual methods have an implementation and provide the derived classes with **the option** of overriding it.
while Abstract methods **do not** provide an implementation and **force** the derived classes to override the method.
Thanks for sharing.
Oh my God !! 8 years after school, I for the first time, understand what is an abstract class. And the differences with an interface !
Thank you very much Monsieur Tim Corey
I am glad it finally clicked.
A short video that absolutely nails it!
"A truck is not a car."
True... but a truck is a vehicle, and so is a car. So your base class would be vehicle and car and truck would be child classes since they have similar properties. A motorcycle is also a vehicle, as is a tractor. And all of them implement similar properties.
Thanks!
I laughed out loud when auto generated subtitles said "a toilet on Tundra is not a car" at 17:52
great explanation btw, I think I understand all now
I work hard on the pronunciation, but once in a while...
Thank you, Tim. If you find that I thank you more than once for the same video, it's because sometimes I watch the same video a lot of times :) (I wish I could learn only by watching the video once)
You are welcome. I am glad they are helpful and I am glad you are using them as reference material. That is how I intend for them to be used - they are visual archives of how to do things in C#. Even I refer to them sometimes.
This video was sufficient enough in the explanation in the sense that I can have that "Oh yeah," moment while working. Thing is you have so many options to do the same thing and everyone will tell you something different on how to implement a solution. Sometimes you just need to be aware of a useful functionality.
Thanks for trusting Tim and watching
I don't know if you still read your comment but man you're a amazing. Thank you very much. Teaching the basic, base, interface cleared up a lot of stuff for abstract classes.
You're very welcome!
Before this video I thought I understood what an abstract class is and how it works. Now I can certainly say I know way better than I used to. Thank you Tim! Awesome video!
Glad it was helpful!
I finally understood the use of abstract class !! Thanks for your great video
Awesome!
Thank you for always explaining things in a calm and structured way!
You are welcome.
I have taken many classes, and I can certainly say that you are very good at teaching. It is a pleasure to learn. I will certainly be purchasing classes.
I appreciate the kind words.
thank you again for a simple explanation of something that seems complex
You are welcome.
Wow you picked a great example to explain this. Also the explanations themselves are super understandable. In just 20 minutes you explained this way better than my teachers did in multiple lessons. It helped me a lot, thank you!!
I am glad it was so clear and helpful.
Thank you for making this video. It absolutely helped me remove the fog in my mind and made it easy for me to explain Abstract Classes to my son.
Excellent!
Once you start talking i get this weird awesome vibe that keeps the whole thing intersting to me. You are a wonderful tutor sir, and we are very grateful for what you're doing!
I'm glad I keep your attention.
You're honestly the best Tim!! Your videos have helped me grasp the foundational topics so much, and I just love the way you explain concepts in such a clear and concise manner. Thanks loads!!!
Thank you!
WOW! clear and concise the best explanation I have found of abstract classes
Thank you!
Thanks, I know of the use of words "virtual", "abstract" in C#, but it just started to get messy in my head on what's the actual difference between interface and abstract. Now it's clean for me again!
I am glad it was helpful.
This level of knowledge needs to be made illegal, Wow!! such clarity and finesse!
Thank you so much @IAmTimCorey
I’m glad it was helpful.
Tim, Bob Tabor and Kudvenkat are my teaching guru
Thank you!
Thanks for this, I have been reading a book that is heavy on the how and light on the why/when. Your concise explanation helped me to understand the use cases for abstract classes better.
Excellent!
that was so perfect oh my god you're like the god of I can teach everything to anyone... amen
lol, I am glad you enjoyed it.
Interfaces and and abstract classes got even more similar in C# 8 since you can now define default implementations of interface members.
Yep, there are definitely more similarities, but their purposes have not changed. Don't use an interface in place of an abstract class just because it can have default implementations. That will cause you nothing but pain. Default implementations cannot be used on concrete classes, just with variables that use the interface. Also, they aren't designed to act like abstract classes. They are designed to allow us to upgrade interfaces without breaking legacy code.
Writing my 70-483 c# exam soon and your videos definitely helps me prepare much better!
Great!
0:00 - Intro
0:58 - Demo application walk through
3:19 - Creating a base Class
5:53 - Making the base class abstract
8:44 - "Interface portion" in the abstract class. The blend of interface and base class
12:56 - Class inheritance in abstract class
16:00 - When to use abstract class
Thanks! I updated the description.
Clear explanation and presentation on abstract classes. I like the way you bring the practical side more into your videos rather than presenting only theoretical aspects.
Thank you!
love this! I'm studying for my promotion exams to become a mid level software engineer. i am feeling confident!
Great!
Hi Tim. Thanks for your great vid as always. Can you do a mini course on Data structures and algos with C#. That will be great!
Thanks for the suggestion. Please add it to the list on the suggestion site so others can vote on it as well: suggestions.iamtimcorey.com/
Man, this is really great. I swear I have had so much trouble figuring out abstracts, delegates, and interfaces but these 3 videos changed that. I will be purchasing the full versions of your lessons and learning c# here from now on. I like to re write the code on my own to make sure I understand what each line is doing, and then trying to create my own examples after it helps it stick.
Awesome! I'm glad they were so helpful.
Thank you alot, I will never forget this.
You are welcome.
thanks Tim for giving amazing hands-on insights.
You are welcome.
🥺😪Thank you so much, this helpled me complete my assignment and i got a distinction 🎊
Awesome! Congratulations.
Your videos are the best, Thanks for all the great content!
You are welcome.
This is such a basic topic, but also a typical interview question!
Yep.
Very clearly explained, it was fuzzy in my mind before but now I understand what and why you might use abstract items. Thanks!
Glad it was helpful and clear!
This is really good explanation. Whole video is good, later part i liked most. Right we should not use concept because it is there but should be very careful on where it fits perfect specially in case with inheritance as it must maintain Is-a relationship. Thanks Tim!
Excellent
Thank you for your time and effort, this really helps me getting better, I just have a hard time understanding all the different classes and how to use them all together with interfaces, its a hard topic to be honest (or I am just a slow learner that is possible aswell)
It is a hard topic. It helps if you start using them (even if you don't fully understand them) in demo projects. As you see how they work, you will get a better grasp on them.
@@IAmTimCorey True that, I try to work with them everyday now making small demo's just for fun, it does help me understanding them all better, and I come watch a lot of your tutorials they are really helpful. At this moment I am following a course for C# and we just started with classes and interfaces (& generics). Everyday its going better, its awesome to see myself improve. Thanks again and have a nice day
1. Same as an abstract class, an interface can't be instantiated, so why would I use an abstract class?
2. Same as an abstract class, an interface can have a method with body to share common logic, so why would I use an abstract class?
3. Same as an abstract class, an interface can force you to implement a method declaration as a contract, so why would I use an abstract class?
The only difference I see is the virtual keyword, which would allow you to override an already defined method from the base class, which you can't do with an interface, but other than this, I can't point a situation where an abstract class is a winner over an interface from the point of code syntax. The only place where it makes a difference is in the way that we think about them, but coding wise, we can achieve the same result with both of them in 99% percent of cases.
What would be that 1% where abstract classes should be used? Maybe I'm not experienced enough but I feel like this question is not answered in your videos.
First, this video was made before default implementations in interfaces was a thing. Second, I think you have a misunderstanding of default implementations in interfaces. Let me talk you through it.
Interfaces are just contracts. They say what a class is going to do. You can have multiple interfaces on one class. It isn't about code sharing, it is about being similar in some way. For instance, you can implement IDisposable, which will allow you to use your class with a using statement. There is no code shared and the classes otherwise have no relationship to each other.
Abstract classes are about a relationship structure ("is a" relationship). The value of an abstract class is the establishment of the commonality of the structures with potentially shared code.
Later on in .NET, they added default implementations for interfaces. This was not to compete with abstract classes or inheritance, and it was not to add multi-inheritance. What it was designed for was the scenario where you had an interface in production. Multiple classes use it. Now imagine you want to add an additional method to the interface. You can't do that without updating all of your existing classes. The solution at the time was to create a new interface. That is inefficient and confusing. So, the solution was to create default implementations. That way, you could add a new method to the interface without breaking the existing implementations by adding a default implementation. However, this is not the same thing as inheritance. For instance, you cannot call that default implementation unless you cast the instance to the specific interface type. So it isn't really usable as inheritance. It is just there to stop applications from breaking when you add to an interface.
Thanks a lot for taking the time to explain this to me. I missed the point of upcasting to the interface if you want to call that method defined there. Otherwise, I feel like C# doesn't make a great job separating this two well enough to help beginners or intermediate programmers. It's very confusing. KUTGW! I really enjoy your channel.
@@IAmTimCorey Please explain this
Same as an abstract class, an interface can force you to implement a method declaration as a contract, so why would I use an abstract class?
Really good explanation for basic approaches. Good to have you here!
Thank you!
Best explanation. Understood finally! Thanks a lot.
You are welcome!
Bravo Tim!Sei molto bravo!
Thank you.
Great Video Tim !! How do we decide when to use Abstract class and when to use an interface? Also can we achieve Dependency Inversion through Abstract Class?
Good question. In order to use an abstract class, you need to have an "is a" relationship. So a cat is an animal, so CatModel could inherit from AnimalModel (possibly). Inheritance is a lot harder to use than people think. Remember that you can only inherit from one parent so while the promise of code sharing is great, you can't just use it as a mechanism to not write duplicate code. You need to be very careful about that relationship. When it is done right, though, inheritance (which is what Abstract classes are) can be powerful. For most scenarios, though, Interfaces are the better option. You can have multiple, they can be specific to your needs (look at the Interface Segregation Principle), and they don't imply a relationship. Dependency Inversion really doesn't do well with Abstract classes because you are still somewhat dependent on that abstract class. It is better accomplished with Interfaces.
Thanks for clarifying Tim!!
Great job with the video, you got me out of a serious headache!
Glad I could help.
@@IAmTimCorey Your videos are great! Helped me a lot starting my job as a junior!
Great presentation as usual. But this video would feel a bit "in there" for someone new to OOP in general. I think a longer video on architecting software, where requirements are discussed first before a design is created, will remove any cobwebs surrounding the use of Base classes vs Abstract classes vs Interfaces. Given your teaching style, it would become a definitive video on this subject on TH-cam.
That's what I do with my start to finish courses. I try to show you these things in the real world.
This video helps to get a quick recap on almost benefits of abstract classes.. Great!
Excellent!
This could represent for me the BIG ANSWER I was looking for!
Thanks a lot, Tim! :)
You are welcome.
Great explanations as usual! Thank you Tim!
You are welcome.
Excellent insightful video tutorial, thanks!
Great!
Hi Tim, please teach us about Aggregation, Composition and association. Great videos btw.
I'll add those suggestions to the list. Thanks.
Wow. in 20 minutes I finally understand what an abstract class is. I have over complicated this in the past.
Are you on Udemy?
Not yet. I do sell courses at www.iamtimcorey.com I may sell (different) courses on Udemy one day but not for a while.
@@IAmTimCorey That "one day" is 3 weeks ago! :) www.udemy.com/user/timothycorey/
Thank you so much for taking your time and making all these videos. Appreciate your efforts !!!
I would like to know if you are planning to make a video on Reflection ?
It is on the list. I've been avoiding it a bit because it is such an abused topic (reflection is rarely the correct answer) but I'll cover it at some point.
Glad to hear that, I'm interested too
Thanks for your videos! They have been helping me a lot!
Great!
In C# 8, you can now add default implementations to interfaces, which lets you avoid code repetition without using abstract classes. Though it's mostly meant to add methods to an interface without breaking existing classes that implement it.
I wouldn't use them in place of abstract classes, though, because they aren't the same thing. Those methods are only available if you use the interface type, not if you use the concrete type or a different interface type. Default implementation does not replace abstract classes.
Thank you Tim you make me understand the benefit and different between abstract and interface and virtual modifier, I studied java but not understand.
Glad it was helpful!
Really helpful and awesome for beginners not to struggle, like some of us, later down the road😊! Do you have any “best practices” for designing the sql(or any relational) data structuring? Keep on rocking, C# for life!
I have a course that covers the best practices for designing a SQL database: www.iamtimcorey.com/p/sql-databases-from-start-to-finish
Do you have a video on how to use helper classes in situations where abstract classes are not optimal?
Hello, I usually use interfaces for everything, but how do I know when it's the right time to use an abstract class as well?
When you have default implementation of a method use abstract class
@@KrishnaGupta-zl7dt Do you mean like connection string of sql server something like that?
@@AonyjsViolmlar05 I am not sure if we are on the same page
@@KrishnaGupta-zl7dt you said if having default implementation of methods i was thinking of sql insert, update, delete. Since it a default craud behavior.
lol I've got the opposite problem. i was taught towards using abstract classes so i never learned interfaces 🥺
Great explanation Mr. Tim, thanks, could you cover please the best practices to make commercial applications
I am going to cover this in an upcoming series.
Excellent & clear as usual, thanks Tim!
You are welcome.
Best explanation by miles, thanks Tim!
Thanks!
This "IS A" fabulous video. 😃
Thank you!
Good video. Sometimes I find it challenging to figure out when to choose "composition over inheritance". You mention interfaces here, and also how not to treat a car as if it were a truck. Perhaps a future video delving into how/when to choose composition over inheritance. For example, instead of having a car and truck inherit from an abstract vehicle class, just have them both implement the IDriveable interface? ... it's probably one of those situations where there's no right/wrong way, so a video looking at the tradeoffs of doing composition vs inheritance might help. BTW, as I write this I see the Composition Over Inheritance wikipedia page has been flagged as "confusing" since 2015.
Thanks for the suggestion. In general, I default to composition because inheritance is really such a small target. However, it does depend on the situation. I agree that it can be very confusing. I'll add the suggestion to my list.
Great Tim. Very clear explanation
Glad it was helpful!
Good Video, Covers Everything i want to know about abstract class
Thank you!
You explained it well, thanks for your educative video
Thanks for investing your time with Tim.
This a great way to showcases the usage of an abstract class, thanks, Tim!
I've worked in different companies and we were using C# as one of the development languages, but I didn't see any usage of an abstract class.
My question is: Is it necessary to use abstract classes to achieve the best practice?
It depends on the situation.
Youve forgotten to demonstrate hiding case when LoadString doesnt have virtual so developetr would have to use new instead of override. That would add a cherry on top of this pice of cake.
I was trying to stick to the things unique to abstract classes and not re-teach class inheritance. I get your point, though.
Great video, very clear explanation, thanks Tim.
You are welcome.
@@IAmTimCorey Tim, one question if I may from your videos I understand that interfaces can have properties and methods (WITHOUT code in them), and abstract classes can have abstract and virtual methods (WITH or WITHOUT code in them), but not properties. Is that correct? Is that another way to differentiate when to use an abstract class and when to use an interface?
Thanks.
You can have properties in an abstract class.
what other 5 videos are you talking about, btw thanks, after Advanced Topics in c#, what i must learn? loveyou bro
Probably the SOLID videos. Here is a playlist with them in it: th-cam.com/play/PLLWMQd6PeGY3ob0Ga6vn1czFZfW6e-FLr.html
As for what to learn after advanced topics, you need to be practicing what you learned. A LOT. By the time you get to advanced topics in C#, you should probably have 200-300 practice projects (small ones) done that practice the individual topics you learned. You should also have 2-5 larger practice projects completed as well. Projects like the Tournament Tracker or TimCo Retail Manager projects here on this channel. It isn't about having seen a bunch of topics, it is about having actually used those topics in an application to validate that you understand how to use them well.
Thank you so much for your video! Your videos are really helpful!
You are most welcome. Thanks for watching.
Great explanation. Thanks a lot Tim.
You are welcome.
Hi Tim, I have a question.
For initializing objects, we do something like this.
class Program
{
static void Main(string[] args)
{
var demo = new DemoClass() {iD=1,Name="vinay" };
var demo2 = new DemoClass() { iD = 2, Name = "Vikas" };
var demo3 = new DemoClass { iD = 1, Name = "vinay", Address = "s", number = 3 };
Console.WriteLine(demo3.Address);
}
}
public class DemoClass
{
public int iD { get; set; }
public string Name { get; set; }
public int number { get; set; }
public string Address { get; set; }
}
demo2 object is initialized as var demo2 = new DemoClass() { iD = 2, Name = "Vikas" };
But in demo3 object, I dont use () after new DemoClass but still works fine and gives correct results. Am I doing something wrong here or i didn't understand some concept.
Thank you for your time.
demo2 and demo3 are the same thing. It is just that demo3 implicitly uses the default constructor while demo2 explicitly states that it is using the default constructor (the one with no parameters).
Wow. Thank you very much!
You are welcome.
Fantastic explanation, thanks so much!
You are welcome.
You are the best!
Thanks much.
Thanks!
Very clear explanation, thank you.
You are welcome.
Yet another awesome one!
Thanks!
Hey, Tim! I didn't get the part of writing DataAccess da = new SqliteDataAcces(); instead of SqliteDataAccess da = new SqliteDataAccess(); could you explain again why we do DataAccess da = new SqliteDataAcces(); ? It's about 11:35.
By using the base class, we can change out the implementation (in this case SqliteDataAccess) for any other implementation without needing to change anything else in our code.
@@IAmTimCorey hi Tim following on .....as @PwnUser mentioned ....Would .....SqliteDataAccess da = new SqliteDataAccess(); produce the same implementation (da object) as............ DataAccess da = new SqliteDataAcces() ......if not ...how would it differ ? (thank you)
Great video, Thanks Tim. but what is ur opinion on using the interface IDataAccess for the DataAccess class and then use the DataAccess class as an abstract class ?
great tutorial. thank u so much
You are welcome.
Good guy Corey thanks! :)
You are welcome.
very clear, thanks!
You're welcome!
Very informative..thank you so much..
You are welcome.
Okay this is some super impressive stuff
Thank you!
very clear explanation,tanks!
You are welcome!
Thanks a lot Corey..
You are most welcome. Thanks for watching.
Abstract classes are best when the code is similar AND/OR you require a concrete default method to be inherited. Otherwise you should use an interface. Interfaces are awesome because you can do inversion of control with them.
They are both pretty great tools to have in the toolbox.
Hi Tim, very instructive and pleasant time I had watching the video. I may also say: as usual... (lol) I'm looking out for how to use abstract classes for a CRUD project using C# and Winform. Your exemple really light me up my candel. Still, because I'm rookie, I need some more tips. Can you tell me where I can find more about how to construct an abstract CRUD class? Regards
I don't have any specific videos on that. Sorry. However, you can watch my videos on the TimCo Retail Manager and Suggestion Site to see how I set up CRUD operations in those videos. Those might help give you some ideas on what you are looking to do. I will say that I don't quite see how you are expecting abstract classes to help you out with CRUD operations. Almost certainly you aren't going to do simple, predictable reads and writes on your tables.
Wonderful explanation Sir. Thank you. Do you have any video upload on Generic IEnumerable ?
Not specifically but I use it multiple times (usually the concrete type List).
A really good video.... Thank you so much for this...
You are welcome.
Hi there. I have set myself in a scenario where I'm not entirely sure of which approach of the base class, abstract class or interface would be the most beneficial. Your example is great, however, I may have gone a step further the complexity of what I'm trying to achieve. Now just for fun, I thought it would be fun to write something like a simple game. Nothing flashy, just in the console to play around with the core logic itself. So with the ide to simulate combat between two characters, like the player and a monster. I thought as a player and monster are both a character when you describe the entity. So at first having an abstract class Character which the class Player & Monster inherits seems about right. So that's grate I can put everything that describes a character in the character abstract class and use it as a blueprint. However, the mind wrapping thing began when I started to set up the structure for spells, Equipiable items and different damage types, as I found to that a class can only have one base class. So that pushes me towards Interfaces, which in my eyes are more a light blueprint compared to a base class which can contain logic for inheritance as well. What confuses me is how to set up a logical hierarchy in this scenario.
I've been there. It all comes down to your last sentence. Plan the logic in paper first, and then jump to coding. As Tim says: "plan before you build". I used to make the logic on the fly along with the code and some loosely coupled ideas... trust me, fun becomes a mess in no time.
@@jonatancordoba7984 yes it really helps visualize the concept with a mind map. After some try and error, interfaces seams to be way to connect everything else with character that is not a natural attribute.
I typically lean towards interfaces by default unless I see a clear need for base classes. That leads to less headaches that way.
Clear explanation , thanks ton
You are welcome.
Great! I really understood what abstract classes are. So do you suggest to use interfaces whenever possible instead of abstract classes?
I would lean that way, but there are still reasons to use abstract classes. They just aren't as common as people initially think.
Perfect Explanation!
Thanks for watching and sharing your thoughts.
Thanks for the video although it was difficult and a bit incomprehensible for me
You are welcome.
Thank you so much!
You're welcome!
really amazing job. thanks.
You are welcome.
Welcome back Tim..
Thanks.