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
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.
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
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.
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.
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.
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!!
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!!!
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!
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.
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!
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!
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
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
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.
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.
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.
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!
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?
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 RUclips.
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.
@@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.
@@KrishnaGupta-zl7dt you said if having default implementation of methods i was thinking of sql insert, update, delete. Since it a default craud behavior.
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.
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.
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)
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).
Love your tutorials and the way you explain! Currently working on a project to learn more about polymorphism. I haven't yet started using interfaces that much, mostly it's abstract classes. Since I've always needed properties and I set them abstract because the subclasses have to add values to the properties. I'm using the abstract class as the base model, for example a car. The car needs the abstract properties of model, year, color etc. Then you create a sub class called Volvo where you add Volvo cars. When would you want to use virtual instead of abstract for an property, if it has a default value set in the abstract class? Do you need to return the properties to the base class in the constructor? public Car(string name, int year) : base (name, year) { Name = name; Year = year; } Or can you skip that part with abstract classes, since the properties in the base class is abstract? For interface you can only declare public methods/variables right? Where as in abstract you can do protected and/or private fields. So when would you rather want an interface over an abstract class? Could you do an interface with all the public fields that the abstract class then inherits from, or is that not necessary? If I get it right, you could for example do an interface called IItem, that shows the public fields that the Item needs. Then you create some base abstract classes that inherits from the interface, example a class for Weapon, Armor, Shield. Then you have classes like Sword, LeatherArmor, Buckler that inherits from the abstract class of Weapon, Armor, Shield? Sorry for the long post, looking forward for more tutorials! :)
In general, code should be more about interfaces than abstract classes because an abstract class means a relationship. Interfaces do not imply a relationship, rather a set of related properties and/or methods. For instance, the IDisposable interface can be used by any class (both the Dog class and the House class can implement IDisposable). The same cannot be true for abstract classes. Even if House and Dog shared a property called Age, that doesn't mean you should create an abstract class that has Age in it and have both inherit from it. There isn't a relationship there. As far as using virtual instead of abstract for a property, it would only be if you wanted to add getter or setter logic in a child class. Properties should rarely be abstract or even virtual. There isn't usually a point. You create them once and then leave them alone.
Thanks for the reply. Alright, I think I need to rethink this then. The examples I have followed have used abstract classes, but as you say Interfaces are in general used more widely. I need the properties to have a protected set, which I can't add directly into the interface, but I can do in the abstract class. Which is why I went with the abstract class. For an example, if I create the interface IEntity. This will then be used to create both Players and NPCs since both are entities. The player can chose from different classes (Warrior, Rogue etc), each hero class have different stats that are set with properties. Should I just make a non abstract class of PlayerBase, which then the classes of Warrior, Rogue inherits from? And PlayerBase inherits from the interface? And instead of a virtual properties that the hero classes override, it's better to use a constructor that return them to the base class of PlayerBase?
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, 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 ?
Probably the SOLID videos. Here is a playlist with them in it: ruclips.net/p/PLLWMQd6PeGY3ob0Ga6vn1czFZfW6e-FLr 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.
I have heard of it and I'm keeping an eye on it. I'll be doing a video or two on it in the future, but not until it stabilizes a bit. I wouldn't want to give the impression that I'm encouraging people to use a technology when it isn't ready yet. As it becomes production ready, I'll be about ready to do a video on it.
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.
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.
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.
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.
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!
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!
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
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 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...
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.
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.
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!
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.
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.
Thank you for always explaining things in a calm and structured way!
You are welcome.
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!
I finally understood the use of abstract class !! Thanks for your great video
Awesome!
WOW! clear and concise the best explanation I have found of abstract classes
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!
thank you again for a simple explanation of something that seems complex
You are welcome.
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.
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!
Writing my 70-483 c# exam soon and your videos definitely helps me prepare much better!
Great!
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.
Tim, Bob Tabor and Kudvenkat are my teaching guru
Thank you!
love this! I'm studying for my promotion exams to become a mid level software engineer. i am feeling confident!
Great!
Your videos are the best, Thanks for all the great content!
You are welcome.
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
Really good explanation for basic approaches. Good to have you here!
Thank you!
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!
thanks Tim for giving amazing hands-on insights.
You are welcome.
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.
This could represent for me the BIG ANSWER I was looking for!
Thanks a lot, Tim! :)
You are welcome.
Thank you so much Tim Corey. This was amazing.
You are welcome.
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.
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
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/
Great explanations as usual! Thank you Tim!
You are welcome.
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.
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!!
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
Best explanation. Understood finally! Thanks a lot.
You are welcome!
Bravo Tim!Sei molto bravo!
Thank you.
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/
This video helps to get a quick recap on almost benefits of abstract classes.. Great!
Excellent!
Excellent insightful video tutorial, thanks!
Great!
🥺😪Thank you so much, this helpled me complete my assignment and i got a distinction 🎊
Awesome! Congratulations.
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!
Thank you alot, I will never forget this.
You are welcome.
Hi Tim, please teach us about Aggregation, Composition and association. Great videos btw.
I'll add those suggestions to the list. Thanks.
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
Thanks for your videos! They have been helping me a lot!
Great!
Best explanation by miles, thanks Tim!
Thanks!
Excellent & clear as usual, thanks Tim!
You are welcome.
This is such a basic topic, but also a typical interview question!
Yep.
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.
Great video, specially the pitfall at the end!
Thanks!
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.
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!
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 RUclips.
That's what I do with my start to finish courses. I try to show you these things in the real world.
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!
Yet another awesome one!
Thanks!
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.
Clear explanation , thanks ton
You are welcome.
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 🥺
This "IS A" fabulous video. 😃
Thank you!
Great explanation. Thanks a lot Tim.
You are welcome.
Good Video, Covers Everything i want to know about abstract class
Thank you!
Thank you so much for your video! Your videos are really helpful!
You are most welcome. Thanks for watching.
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.
You explained it well, thanks for your educative video
Thanks for investing your time with Tim.
Fantastic explanation, thanks so much!
You are welcome.
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.
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)
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).
Love your tutorials and the way you explain! Currently working on a project to learn more about polymorphism.
I haven't yet started using interfaces that much, mostly it's abstract classes. Since I've always needed properties and I set them abstract because the subclasses have to add values to the properties.
I'm using the abstract class as the base model, for example a car.
The car needs the abstract properties of model, year, color etc. Then you create a sub class called Volvo where you add Volvo cars. When would you want to use virtual instead of abstract for an property, if it has a default value set in the abstract class?
Do you need to return the properties to the base class in the constructor?
public Car(string name, int year) : base (name, year)
{
Name = name;
Year = year;
}
Or can you skip that part with abstract classes, since the properties in the base class is abstract?
For interface you can only declare public methods/variables right? Where as in abstract you can do protected and/or private fields.
So when would you rather want an interface over an abstract class? Could you do an interface with all the public fields that the abstract class then inherits from, or is that not necessary?
If I get it right, you could for example do an interface called IItem, that shows the public fields that the Item needs.
Then you create some base abstract classes that inherits from the interface, example a class for Weapon, Armor, Shield.
Then you have classes like Sword, LeatherArmor, Buckler that inherits from the abstract class of Weapon, Armor, Shield?
Sorry for the long post, looking forward for more tutorials! :)
In general, code should be more about interfaces than abstract classes because an abstract class means a relationship. Interfaces do not imply a relationship, rather a set of related properties and/or methods. For instance, the IDisposable interface can be used by any class (both the Dog class and the House class can implement IDisposable). The same cannot be true for abstract classes. Even if House and Dog shared a property called Age, that doesn't mean you should create an abstract class that has Age in it and have both inherit from it. There isn't a relationship there.
As far as using virtual instead of abstract for a property, it would only be if you wanted to add getter or setter logic in a child class. Properties should rarely be abstract or even virtual. There isn't usually a point. You create them once and then leave them alone.
Thanks for the reply. Alright, I think I need to rethink this then. The examples I have followed have used abstract classes, but as you say Interfaces are in general used more widely.
I need the properties to have a protected set, which I can't add directly into the interface, but I can do in the abstract class. Which is why I went with the abstract class.
For an example, if I create the interface IEntity. This will then be used to create both Players and NPCs since both are entities.
The player can chose from different classes (Warrior, Rogue etc), each hero class have different stats that are set with properties.
Should I just make a non abstract class of PlayerBase, which then the classes of Warrior, Rogue inherits from? And PlayerBase inherits from the interface?
And instead of a virtual properties that the hero classes override, it's better to use a constructor that return them to the base class of PlayerBase?
Okay this is some super impressive stuff
Thank you!
You are the best!
Thanks much.
Thanks!
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?
Very informative..thank you so much..
You are welcome.
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 ?
Welcome back Tim..
Thanks.
Very clear explanation, thank you.
You are welcome.
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: ruclips.net/p/PLLWMQd6PeGY3ob0Ga6vn1czFZfW6e-FLr
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.
Wow. Thank you very much!
You are welcome.
very clear, thanks!
You're welcome!
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).
very clear explanation,tanks!
You are welcome!
Perfect Explanation!
Thanks for watching and sharing your thoughts.
really amazing job. thanks.
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.
Good guy Corey thanks! :)
You are welcome.
A really good video.... Thank you so much for this...
You are welcome.
Hi Tim, have your heard of Blazor? What you think of it? Could be useful for front-end web applications? About making an upcoming videos about it?
I have heard of it and I'm keeping an eye on it. I'll be doing a video or two on it in the future, but not until it stabilizes a bit. I wouldn't want to give the impression that I'm encouraging people to use a technology when it isn't ready yet. As it becomes production ready, I'll be about ready to do a video on it.
really great explanations
Glad it was helpful!
Another great one!
Thanks again!
Thank you so much!
You're welcome!
Very helpful, thank you
Great!