Because either: 1. They are not interested. 2. They do not practice or apply SOLID 3. They are much genius than us 4. Competitors 5. No brains at all!!
People buy likes from companies that use bots to distribute those likes. UA-cam shutdowns the accounts used by these bots when they are detected. These bots must also give dislikes to avoid detection and do so on random videos. Chances are almost no one actually disliked this video.
Probably the best series about SOLID UA-cam can offer! Although I write code in Java, it doesn't matter because it is perfectly explained. Thanks for this!
At 24:00 I was thinking, "That's a crap-ton of interface files for four classes." At the 30:00 you alleviated that concern (somewhat). Yours is some of the best teaching content available. Thanks!
Thanks for the lesson! Few questions: -Why wouldn't you make an abstract class BorrowableMovie which implements the general interfaces? DVD and DigitalMovie could both enherit from abstract class BorrowableMovie, and you would have less repetition. -Is is common to have properties in interfaces? I was taught interfaces are about behavior/mehods. You could place the properties in the abstract class that implements the interfaces. I guess I'm mostly struggling with when to use interfaces and when to use abstract classes.
Definitly the best explanation of SOLID, thanks for every minute. Those who find out why he combine two interface instead of implement 3 interface, jump 25:00.
Ideally, you would create an IBorrowService, which will handle the 3 methods for you, in stead of having the same implementation in multiple classes. You could throw in any IBorrowable, wether is a Book, AudioBook or DVD. The IBorrowService wouldn't really care about that. I think is also more compliant with SRP and DRY. Thank you for this well explained video on ISP Tim!
This was an outstanding learning video. A good real life example and now everything is just crystal clear to me. Even things from the Open/close principle, that was a little difficult to understand before, became much clearer after watching this one. Thank you SO much for sharing this.
Thank you Tim, among UA-cam channels, yours is one of the most valuable. Very explanatory videos. At times I wish nobody would see these videos but me, so I only be able to get this precious knowledge :) A special thanks for answering to all comments, what a great respect!
You are welcome. Don't worry about knowledge sharing. It lifts us all up. If you get to the point where you are a senior developer, the way to take your skills to the next level will be to teach (it really stretches your skills).
One of my favourite videos from you in SOLID and not only. Ikinda still see it all foggy, all these concepts in programming, so interfaces where still kinda abstract for me, but this made soo much sense. You the man. :D
Very good explanation of a high level concept that isn't always so obvious. Retraining the brain to develop this way is a tough task. Luckily, you make that task a lot easier. Thanks.
What a great material. This series about SOLID has proven to be very handy to me. I am looking forward to seeing the next episode and also a new tutorial about interfaces, with complexity scenarios perhaps, that would definitely be useful. Thanks a million!
I have seen some videos about interfaces around. Most of them explain the theory and give an extremely vague example of its implementation, like adding properties and implement those properties or basic methods. In my humble opinion, this is not what will teach people how to use interfaces, and specially realise how powerful it is. What I mean is that I wanted to see an implementation of a Connection perhaps, so let's say we have to implement two kind of connections, one for SQL Server and other for Oracle, or an external API. An implementation of a logger, anything that we really see the Interface's power if you know what I mean.
@@IAmTimCorey It seems like I had many questions of this sort that this topic addressed. I always wondered for instance, why there is Enumerable and IEnumerable and what is the decision making process of using one vs. the other. So nice to learn where I can focus to get the answers.
I can appreciate your reasoning behind the IBorrowableDVD mixed interface between IDVD and IBorrowable, but in practice, I feel like that concept quickly grows out of control. What if some borrowable items can be borrowed for free, and others have a price? Maybe you would decide to have an IBorrowable and an IHasCheckoutCost. Then suddenly you have some IBorrowables which have a cost and some that don't, and creating the combination interface explodes into IBorrowableDVD and IBorrowableDVDWIthCost, IBorrowableBook and IBorrowableBookWithCost, etc.. Maybe you decide to inherit from the DVD class to have an EducationalDVD and an EntertainmentDVD, the difference being EducationalDVDs are free to borrow (implement only IDVD and IBorrowable), while EntertainmentDVDs come with a check-out cost (implementing IDVD, IBorrowable, and IHasCheckoutCost). Perhaps a slightly contrived example, but the point is just that, while I can appreciate the concept behind combining interfaces, in practice I'm a bit skeptical of whether it's a good idea. Besides, if there isn't enough information in IBorrowable to perform any necessary actions without casting (such as CheckOut(IBorrowable borrowable)), doesn't that point to a flaw in the design of IBorrowable itself (such as having no Title)? In practice, having to choose between an IDVD and an IBorrowable wouldn't be an issue, because I'd just keep the type as DVD to have both.
It can definitely get tricky and you need to consider your use cases before embarking on this path. However, the point with ISP is to not lock yourself into creating interfaces that have everything and thus force yourself to "implement" things that aren't really there. Using smaller interfaces that can inter-connect, you can more easily design what you want without locking yourself into a bad situation. Don't forget that you can do casting to other interfaces if you have a list that contains items you want to perform multiple actions on (borrow and view title for instance).
Thank you for the series of SOLID, every principal explanation in your video are very useful and very make sense, i'v tried to challenge my self to create segregation interface before end of your video , but you did much better :)..
Yeah, it clears that up quickly, doesn't it. Interfaces allow for disconnected applications that are flexible. Just wait until the next one. Here's a hint: we use Interfaces a lot. :-)
Such a great video. Just a suggestion : Personnally I separate Interfaces and Implementations into different folders or even in different libraries and namespace, in order the client and the implementation depends on the interfaces, that are the contract, unless the client knows the implementation. In the idea, it may be the client that define the contract to implement, so the interface is is actually separated from the implementation.
The problem with this is that then the client (the UI) has to have a reference to the class library, which would create a circular dependency (the class library has to have a reference to the UI for the interfaces and the UI has to have a reference to the class library for the implementations).
@@IAmTimCorey Ideed, but by "client", I was meaning the person who define how the class library will be used, so if you talk about the client as the UI, my solution may be to create three separate libraries : one for the interfaces, which define the contract between UI and Business, one for UI and one for Business, and inject Business Dependency in UI by dependency injection in order to respect Dependency Inversion Principle. But I assume it can be overkill
Thanks for such a great and detailed video. At 22:50 I'd rather rename IAudioBook to IMedia and implement IMedia in both IDVD interface and AudioBook class. That would make sence and you don't have to create personal interface for every class. But probably some other use case that fits your explanation exists out there, so I'll keep that in mind for future. Thanks.
Hello, Tim! Great video, thank you for this awesome content! One question on the topic about Intefaces What would you recommend: creating classes first and extracting intefaces or building intefaces structure first and then go to implementation through classes? Basically two paths: Classes -> Intefaces or Intefaces -> Classes Thanks a lot for taking this question
I love this. I watched this after already familiarizing myself with interfaces and dependency injection and lazy initialization. This gave me something to think about when separating interfaces and combining them later for a super interface. Can you do a video on passing dependencies as interfaces (or native types where it makes sense) to the constructor? Skill foundry did a video titled: "Dependency Injection in C# ❘ A Hands-On Guide to Boosting Code Flexibility and Testability" It was great too but I'd like to see an additional twist, throwing exceptions in the getters of the "lazy" properties to cancel the execution of a SQL transaction. Allowing for you to define multiple points of failure where your application SHOULD revert/cancel/undo a SQL transaction that is defined in the entry class. Just an idea (It's also relevant to my current project XD).
Another good one Tim. This reminded me of how the SQL DB tables might need to be split apart (and put together with JOINs). For noSQL, I would suspect you would use the interface hierarchy to know what keys to expect from the JSON response. So good good stuff.
Nice. I'm a visual guy, and I think a Class Diagram would be beneficial to see the hierarchy of how all these Interfaces relate. I tried to create one myself, but I can't figure out how to add the Class Designer to the Toolbox. There is nothing in my Toolbox even after I Installed the Class Designer component from the Visual Studio Installer (I'm using VS 2017 Professional). Oh well. Thanks Tim for you videos, I appreciate them.
Just thinking, In the example mentioned in video, IAudioBook could have been IDigital. In that case IDVD could have implement IDigital and have one extra property Actors solving the DRY issue. Any thoughts?
Great video (even the 3rd time watching). I completely understand what this principal is explaining, however I have recently found myself in a similar situation, but an aspect of the practical implementation is presenting as a challenge. I was curious if you have considered making a video on how to implement some of the more advanced topics. For your example in this video, lets say you have a database, which stored all your 'List libItems'. Say the requirement is to SELECT * from LibraryItems and put libItems into a data grid. The user would then select a row from the grid and this would show the actual TYPE and its respective "Interface" implementation (such as IBook, IBorrowableBook, IBorrowableDVD...).
The way to do this is probably to store the type name in a property (and put it in the interface). This would also allow you to then cast to that type using a switch statement.
Hi Tim. Thanks very much for your videos! They are really helping to get my head around the more complex aspects of OOP. Your clarity is greatly appreciated in a field where even the official documentation is often written in a convoluted way that makes it impenetrable to a beginner. In this video have I understood correctly that it is better to define variables in the application and library classes as the interface rather than the implemented class (eg. IBook book1 = new Book() rather than Book book1 = new Book() )? I struggle to understand how to uncouple classes within a library since they are obviously meant to interact and talk to one another. Does using interfaces in this way serve to loosen the coupling between classes. Perhaps this is more related to dependency inversion?
HI, Please correct me, if my understanding is wrong with below statement Assigning the object to the variable of type Interface helps in the scenarios where we can not determine which object comes into the picture dynamically. In your scenario, if we retrieve borrowable items info from the database . and if we store each record in the list. Means each record describes a thing (DVD or Book or Audio). Then we can assign like below. List b = GetFromDB(); foreach (var item in b) { IBorrowable borrowable = new item(); borrowable.ShipItem(); }
It helps if we don't know the type, but it also helps in that we can store multiple types in the same list. So a list of IBorrowable can have DVDs, Books, and AudioBooks in it.
Great video, but I have a confusion: In 28:00 you said that we should prefer this: IBorrowableDVD dvd = new DVD(); instead of this: DVD dvd = new DVD(); Maybe I missed something, but I don't really get why we should not create the DVD object like in the 2nd option.
Thanks Again Tim!! 14:30 Book Class has things the ReferenceBook does not. Not a huge deal but you would think that a "Book" Class would apply to a "Reference" Book. 23:25 Shouldn't Actors be part of Movie instead of IDVD?
And now I see how I really messed up on a project 10+ years ago and made it super confusing because I was told to use interfaces without understanding how they worked. *sigh* You live, you learn. I still don't want to go back and touch that code again. *shudder*
Hi Tim, at around 28:30 you show why you use IBorrowableDVD by showing how you have access to all the properties which you don't if you implement only IBorrowable or IDVD. My question is, why simply not inherit from a DVD class (DVD that implements IDVD and IBorrowable, the same as IBorrowableDVD interface) and have access to the same properties? Is it because the video is about ISP, or there's more? Personally, I don't see a great use of interfaces that ONLY merge other interfaces and not bring additional stuff into the contract. Thank you for everything you're doing! edit: just remembered another reason for it: unit testing, but again, since it only merges two interfaces, shouldn't testing those two "base" interfaces cover everything?
Please make a video on how to read built-in classes. A few days ago I was trying to see from the controller, how it returns OK/BadRequest as IACtionResult, I knew they implemented IActionResult interface but after opening the class I could not understand how they are working actually. Too difficult to understand as a beginner/intermediate-level developer.
Quick question, why are we not extending ILibraryItem to IBorrowable, they are also a Library item as I understand. Also IBorrowable would not have to have a separate property as a libraryId and Title, as it would simply have the ILibraryItem properties
Hello Tim! There is something i don't get. For example: I have an IPrinter interface with the method Print() , but there are some printers with the capability of sending e-mail's, so i have the IMailPrinter interface with the method SendMail(). Then , i have a software which in case the printer has the capability, has to send an e-mail after making an invoice. So In that case, the client has the IPrinter dependency, the problem is that at the moment of making the invoice, the client has to ask if that dependency has the capability to make one or other action. So, at the end, there is a need to have one or multiple if statements on the UI/Client side, like this : " if (printer is IMailPrinter) { ((IMailPrinter)printer).SendMail()}" and that's not nice. In this case, how can i solve the problem?
You could combine two interfaces so they would have both methods available when appropriate. Otherwise, you will need to do some casting. You can make that easier, though, by doing as follows: if (printer is IMailPrinter p) { p.SendMail();}
My question would be how does this relate to database tables. Say we have a table LibraryItems that has all the needed columns for a library item, and an int column that maps to an Enum to show which type of LibraryItem it is, (DVD, Book, AudioBook, etc). We then have a Model that has matching properties to the DB cols. When we query that table and map it to that matching (entity) model, would that (entity) model for each type, then be mapped to their respective DVD, Book, AudioBook models?
Thanks a lot Tim for the wonderful job again. One question please: it seems we should combine interfaces first then create class to implement the single combined interface, could we sometimes create a class to implement 2 interfaces? Please advise. Thanks again.
Sure, a class can implement as many interfaces as you need. You can only inherit from one class but you can have multiple interfaces against one class.
Wow, so much interfaces. I think I can see generally the use of that in making code, but as this example really shows, to make a good Library apps it would need much consulting with Librarians. Maybe I'm wrong, but for starts I think they first divide Digital an NonDigital publications, and so on, and so on. Whit out that code is just a mess using interfaces or not. Thanks for vids!
That's the key with any application - consult with people who actually use the software. Not just management - the person who has to enter data is even more vital. They can usually tell you the pain points and they can shoot down your "good ideas" if they aren't practical.
I like this SOLID series. However, one question arised: Does it not make sense to have a base class "LibraryItem" instead of the interface - all the books, DVDs and so on are library items, as you mentioned - or did I miss something?
It can make sense to have a base class LibraryItem but not always. If you used that as the base class, that means you can't have a different base class for some items. In our case, that is probably fine but it is something to consider.
@@IAmTimCorey Hello Corey, could you please explain what you meant by having a base LibraryItem class means "you can't have a different base class for some items"?
Hey, great video! However, I have a question, can't we create another interface called IPlayable that implements the property RuntimeInMinutes? That way we don't have to repeat ourselves.
That's the comment I was looking for, right there! My idea was "IPlayableMedia" ... same thing. Right now it doesn't really matter that much for the sake of this one property, but think about the future, new features and scale. In the future an application might want to show a user how much time they've spent playing certain media files or have a system to remember where they left off when they reopen it. The IPlayableMedia interface could end up having more properties like SizeOnDisk, CurrentPosition, UserRating, IsFavorite, etc. The application could operate on these objects through the interface without caring if it's audio vs video: they actually have a great deal in common as media and you'll see similar concepts if you pay attention to software for Windows.
Great tutorial. After going through your LSP and ISP videos of SOLID Principle, i got one doubt. Doubt is in LSP and ISP both, you are segregating into interfaces then implementing those interface into classes. So how these both are different to each other. Please explain.
They both use interfaces but all of the SOLID principles do in practice. The focus of LSP is how objects relate to their parents. The focus of ISP is on how interfaces are developed and used. The focus is on different parts of OOP between the two.
Once again an excellent tutorial : it's even understandable for an absolute C# rookie :). One question though : are those SOLID principles integrated in any of your courses ? I mean by this do you propose any (payable) course integrating "How to build a C# (or any other fully OO language for that matter) implementing the SOLID principles from the ground up ?
Yes and yes. At IAmTimCorey.com, for the more advanced user, we build the TimCo application from Requirements to deployment and also incorporate enhancement cycle. SOLID is used. The UA-cam version of TimCo can be found here also - ua-cam.com/video/Xtt6mS0p2_c/v-deo.html
The library item doesn't need any circulation data. Circulation is a collection that references library items that are not shelved. Circulation Policy determines when and how the items circulate.
Great video. My only question would be how to make an ObservableObject using IMapTypes. When I try ObservableObject booklist = new ObservableCollection doesn't work, but this seems to: public async Task CreateMapList() { return new ObservableCollection { new MapTypes {Id = 0, MapTypeString = AppResources.Hybrid}, new MapTypes {Id = 1, MapTypeString = AppResources.Satellite}, new MapTypes {Id = 2, MapTypeString = AppResources.Street}, new MapTypes {Id = 3, MapTypeString = AppResources.Terrain} }; } Please explain. Thanks
The difference between the two is that in your second example, you are creating an ObservableCollection instead of ObservableCollection. When you instantiated the OC in the first example, you changed to the concrete type MapTypes. That is more restrictive than the declaration was, which doesn't work. You could, however, still assign MapTypes to the more loosely defined ObservableCollection.
Great lesson, really clear and detailed. I'll have to start looking at doing more interfaces in future :) Looking forward to the last one of the SOLID set!
Hi Tim, Thanks for making this video. I have one question though. Why did you create another interface, IBorrowableBook that joins together IBorrowable and IBook instead of just making the book class implement both interfaces? What is the purpose behind that?
Thank you Tim for the video. I've got a question about this. Would it be a good idea to have the IBorrowable interface instead be an abstract class (Borrowable.cs) so that we could help us not repeat ourselves (DRY ?) with properties such as Borrower, BorrowedDate, or the three methods CheckIn, CheckOut, GetDueDate in classes like AudioBook, Book or DVD ? I am just not sure 100% when to use an interface and when to do simple class inheritance with a base abstract class (like we did in the LSP video with BaseEmployee class). I would love to find new system-design exercises like this where I could make these decisions and get better at doing so. Thank you again !
The problem with that is that the elements that would need the Borrowable abstract class are not related tightly enough. Their only real relationship is that they can all be borrowed. This is not the way to use inheritance. It locks you in and causes problems.
@@IAmTimCorey I'm guessing one way to identify this Is to ask "Is B an A object ?" Like you said in this and previous videos ... Books, AudioBooks, DVDs "can be borrowed" (characteristics) but they "ARE NOT A ..." Borrowable object themselves unlike an Employee that IS A Person. Thank you Tim.
Hi! I am a newbie in C# and have some questions :D 1. If i wanna use field, property or function of some class i should do it only by interface? 2. There is a reason to not make base class BaseLibraryItem wchich have only LibraryID? 3. I would really love to see a big structure of for example OrganicLife that have humans, lions, plants, trees, bacteria and fungus - off course within reason ^^.
You can have properties or methods that are not specified in an interface. You just need to cast the type to the given class to use them. As for the base class, that is a possibility but you do need to exercise caution with base classes. They are used to indicate a relationship, not just a code-sharing mechanism. In this case, there is a relationship. However, the other thing to be careful of is that you only get one base class. So, if you decide that LibraryItem is what you want to go with, you can't have your DVD class inherit from the Movie base class.
Great video, but I have one question: if we initialize a variable as IBook or IBorrowableBook - do we get different objects then, with different set of properties and methods?
Thanks Tim for such a crystal clear explanation and also making me understand why to have a combination interface (IBoorowableBook, IborrowableDVD..). Also the example which was taken for this explanation was very much relevant and easy to relate to the realtime projects
What are the pros/cons of creating an empty IBorrowableDVD interface that implements IDVD and IBorrowable vs just implementing those same interfaces directly in the DVD class and then creating instances of the DVD class with the Class type itself like: class DVD : IDVD, IBorrowable ... DVD dvd = new DVD(); I tested it in code and its seems functionally the same. Do you lose some flexibility with an object that is typed by the class instead of the interface that it implements?
Hi Tim, Again, great video. One question: Why do you put IBorrowableDVD and not DVD so reference to the interface and not the class. IBorrowableDVD dvd = new DVD(); DVD dvd = new DVD(); You have the same dropdown intelli. Thanks, Peter
First, to show that you can. Second, you don't have to put a DVD instance in an IBorrowableDVD. If another class used that same interface, you could put that instance in the dvd variable instead.
Hi Tim, Awesome video need one help could you please create one video for GetHashCode() , and please tell me exact difference between Extension mathod and static method. Thanks in advance
How did I miss this video? UA-cam is sometimes really had at suggesting videos from people I am subscribed. This is great for getting you thinking on a different level. Great video! What course or other videos do you have that further explains this? I get this but I would love more examples of you have them.
I do have a playlist that includes all of SOLID and DRY: ua-cam.com/play/PLLWMQd6PeGY3ob0Ga6vn1czFZfW6e-FLr.html I also use these topics in my full projects (TimCo Retail Manager, for example).
Firstly, thank you for the great content. I do have a question based on some digging I did on "empty interfaces" (or more specifically, the issue with accessing members from both IDVD and IBorrowable without the empty IBorrowableDVD interface). Couldn't we solve that issue by using a generic class/method with type constraints for IDVD and IBorrowable? This would serve the same purpose while also enforcing code consistency, since classes could otherwise implement IDVD + IBorrowable or just IBorrowableDVD.
I don’t see the problem you are trying to solve here. A “generic” class to do what IBorrowableDVD does would be a base class. You can often use base classes to replace interfaces but that then implies a strong relationship in all of the children that might not be present in order to replace something that works great.
By far the best video on SOLID! Thank you so much for posting it!!!
I am glad you enjoyed it.
Can't understand why would someone dislike such a great video.
Thanks!
Because either:
1. They are not interested.
2. They do not practice or apply SOLID
3. They are much genius than us
4. Competitors
5. No brains at all!!
People buy likes from companies that use bots to distribute those likes. UA-cam shutdowns the accounts used by these bots when they are detected. These bots must also give dislikes to avoid detection and do so on random videos. Chances are almost no one actually disliked this video.
@@nickfotopoulos5323 lol, that's interesting
They had their sceens upside down and they inverted the thumbs-up and down...! that's the only reason I can thhink of
Probably the best series about SOLID UA-cam can offer!
Although I write code in Java, it doesn't matter because it is perfectly explained. Thanks for this!
I’m glad it was so clear.
Listening to Tim say "borrowable" so many times has made my day for some reason! Joking aside, though, thank you for the great video!
😂
At 24:00 I was thinking, "That's a crap-ton of interface files for four classes." At the 30:00 you alleviated that concern (somewhat). Yours is some of the best teaching content available. Thanks!
Thank you!
In my opinion Tim’s videos on SOLID are hands down the best ones on UA-cam.
Thank you!
Thanks for the lesson! Few questions:
-Why wouldn't you make an abstract class BorrowableMovie which implements the general interfaces? DVD and DigitalMovie could both enherit from abstract class BorrowableMovie, and you would have less repetition.
-Is is common to have properties in interfaces? I was taught interfaces are about behavior/mehods. You could place the properties in the abstract class that implements the interfaces.
I guess I'm mostly struggling with when to use interfaces and when to use abstract classes.
IMO, the best video I've come across explaining and demonstrating the application of SOLID principles. Thanks!
You are most welcome. Thanks for watching.
I finally understood Interfaces thanks to your videos. Thanks Tim !
Excellent!
Best series about SOLID. thank you so much for explan all principle
You're very welcome!
Definitly the best explanation of SOLID, thanks for every minute.
Those who find out why he combine two interface instead of implement 3 interface, jump 25:00.
Thank you.
Ideally, you would create an IBorrowService, which will handle the 3 methods for you, in stead of having the same implementation in multiple classes. You could throw in any IBorrowable, wether is a Book, AudioBook or DVD. The IBorrowService wouldn't really care about that. I think is also more compliant with SRP and DRY.
Thank you for this well explained video on ISP Tim!
Thanks for the suggestion.
I agree with you, but programming is also ART so each programmer is creatively different.
Thank you for making this design pattern series. It's given me more confidence in planning out my code.
You're very welcome!
This was an outstanding learning video. A good real life example and now everything is just crystal clear to me. Even things from the Open/close principle, that was a little difficult to understand before, became much clearer after watching this one. Thank you SO much for sharing this.
Glad it was helpful!
Thank you Mr. Corey, another great video, I only wish I watched this video 5 years ago.
You are welcome.
Thank you Tim, among UA-cam channels, yours is one of the most valuable. Very explanatory videos. At times I wish nobody would see these videos but me, so I only be able to get this precious knowledge :) A special thanks for answering to all comments, what a great respect!
You are welcome. Don't worry about knowledge sharing. It lifts us all up. If you get to the point where you are a senior developer, the way to take your skills to the next level will be to teach (it really stretches your skills).
Thank you very much.
A SOLID precise explanation on The SOLID principles.
Glad it was helpful!
One of my favourite videos from you in SOLID and not only. Ikinda still see it all foggy, all these concepts in programming, so interfaces where still kinda abstract for me, but this made soo much sense. You the man. :D
Great! I am glad it was helpful.
Wow, I finally understand why interfaces are so powerful! Thank you!
Happy to help!
Very good explanation of a high level concept that isn't always so obvious. Retraining the brain to develop this way is a tough task. Luckily, you make that task a lot easier. Thanks.
I'm glad I was able to make it easier for you.
What a great material. This series about SOLID has proven to be very handy to me. I am looking forward to seeing the next episode and also a new tutorial about interfaces, with complexity scenarios perhaps, that would definitely be useful. Thanks a million!
Thanks and yep, I'm thinking I need a video just dedicated to interfaces to go over the what and why of them.
Yes, that's could be very useful.
I have seen some videos about interfaces around. Most of them explain the theory and give an extremely vague example of its implementation, like adding properties and implement those properties or basic methods. In my humble opinion, this is not what will teach people how to use interfaces, and specially realise how powerful it is. What I mean is that I wanted to see an implementation of a Connection perhaps, so let's say we have to implement two kind of connections, one for SQL Server and other for Oracle, or an external API. An implementation of a logger, anything that we really see the Interface's power if you know what I mean.
I wondered about this topic so often. So nice to finally learn the rhyme and reason behind it.
I'm glad the video was able to clear some things up for you.
@@IAmTimCorey yes it was great. I listen to it on one screen, my ipad, and type the code in the other on my pc. That also helps a lot.
@@IAmTimCorey It seems like I had many questions of this sort that this topic addressed. I always wondered for instance, why there is Enumerable and IEnumerable and what is the decision making process of using one vs. the other. So nice to learn where I can focus to get the answers.
Beautifully explained. This approach of teaching concepts is super friendly to human brains.
Thank you!
> super friendly to human brains
That was my first mistake. :D
This is great. It belongs in a playlist.
It is in one: ua-cam.com/play/PLLWMQd6PeGY3ob0Ga6vn1czFZfW6e-FLr.html
I love your videos. Great refreshers before interviews. I am happy that you explain with code examples. Thank you.
You are welcome. I'm glad they are so useful to you.
Thank you for all the explanations, it will change my coding pattern.
Great!
0:00 - Intro
1:49 - Demo Code overview
2:55 - Interface Segregation Principle: ISP Explained
7:45 - Implementing ISP: Refactoring demo code
24:52 - Note on empty Interfaces
29:06 - Recap
30:14 - Organizing code base and note on namespaces
34:47 - Summary and concluding remarks
Thank you!
Good stuff, man... thanks! Hope you have a great day!
@@Bennevisie Yes!
This video series is awesome extremely good, some might call it a really SOLID video series 🤣
Thanks Tim, I’ve learnt a ton from your content
You are most welcome. Thanks for watching.
Thanks for yet another excellent video. One quibble Tim...... You implement interfaces you don’t inherit from interfaces. You taught me that 😁😁
lol, you are correct.
Explained in great detail... nicely done.
Thank you!
I can appreciate your reasoning behind the IBorrowableDVD mixed interface between IDVD and IBorrowable, but in practice, I feel like that concept quickly grows out of control. What if some borrowable items can be borrowed for free, and others have a price? Maybe you would decide to have an IBorrowable and an IHasCheckoutCost. Then suddenly you have some IBorrowables which have a cost and some that don't, and creating the combination interface explodes into IBorrowableDVD and IBorrowableDVDWIthCost, IBorrowableBook and IBorrowableBookWithCost, etc.. Maybe you decide to inherit from the DVD class to have an EducationalDVD and an EntertainmentDVD, the difference being EducationalDVDs are free to borrow (implement only IDVD and IBorrowable), while EntertainmentDVDs come with a check-out cost (implementing IDVD, IBorrowable, and IHasCheckoutCost).
Perhaps a slightly contrived example, but the point is just that, while I can appreciate the concept behind combining interfaces, in practice I'm a bit skeptical of whether it's a good idea. Besides, if there isn't enough information in IBorrowable to perform any necessary actions without casting (such as CheckOut(IBorrowable borrowable)), doesn't that point to a flaw in the design of IBorrowable itself (such as having no Title)? In practice, having to choose between an IDVD and an IBorrowable wouldn't be an issue, because I'd just keep the type as DVD to have both.
It can definitely get tricky and you need to consider your use cases before embarking on this path. However, the point with ISP is to not lock yourself into creating interfaces that have everything and thus force yourself to "implement" things that aren't really there. Using smaller interfaces that can inter-connect, you can more easily design what you want without locking yourself into a bad situation. Don't forget that you can do casting to other interfaces if you have a list that contains items you want to perform multiple actions on (borrow and view title for instance).
Thank you for the series of SOLID, every principal explanation in your video are very useful and very make sense, i'v tried to challenge my self to create segregation interface before end of your video , but you did much better :)..
Thanks!
Great video Tim. After that series I finally understood why I need interfaces.
Yeah, it clears that up quickly, doesn't it. Interfaces allow for disconnected applications that are flexible. Just wait until the next one. Here's a hint: we use Interfaces a lot. :-)
I definitely have trouble thinking in terms of interfaces when programming. Looking forward to the next video.
I love how he pronounces IBorrowable as IBorrowabable, great video by the way. Enjoying this series on SOLID, one more to go 💪
Glad you like them!
Such a great video. Just a suggestion : Personnally I separate Interfaces and Implementations into different folders or even in different libraries and namespace, in order the client and the implementation depends on the interfaces, that are the contract, unless the client knows the implementation. In the idea, it may be the client that define the contract to implement, so the interface is is actually separated from the implementation.
The problem with this is that then the client (the UI) has to have a reference to the class library, which would create a circular dependency (the class library has to have a reference to the UI for the interfaces and the UI has to have a reference to the class library for the implementations).
@@IAmTimCorey Ideed, but by "client", I was meaning the person who define how the class library will be used, so if you talk about the client as the UI, my solution may be to create three separate libraries : one for the interfaces, which define the contract between UI and Business, one for UI and one for Business, and inject Business Dependency in UI by dependency injection in order to respect Dependency Inversion Principle. But I assume it can be overkill
Thank you so much Tim. I'm learning a lot from you.
You are welcome.
Thank you so much, I understand the SOLID principle in details by your videos. Thanks Again
You are welcome. I'm glad they were so helpful.
Combining interfaces using another interface is so simple but so genius.
I am glad it was helpful.
Simply awsome ('Zabardast' in URDU language)
Thanks!
Thanks, Tim. Super useful tutorial.
You are welcome.
Just solved my interface problem. Thanks.
Glad I could help
Thanks for such a great and detailed video.
At 22:50 I'd rather rename IAudioBook to IMedia and implement IMedia in both IDVD interface and AudioBook class. That would make sence and you don't have to create personal interface for every class. But probably some other use case that fits your explanation exists out there, so I'll keep that in mind for future. Thanks.
You are welcome.
or IPlayable
Hello, Tim! Great video, thank you for this awesome content!
One question on the topic about Intefaces
What would you recommend: creating classes first and extracting intefaces or building intefaces structure first and then go to implementation through classes?
Basically two paths: Classes -> Intefaces or Intefaces -> Classes
Thanks a lot for taking this question
Nice simple example. Great for getting the concept. I have always struggled with this and this video helps. Thanks.
I'm glad it clicked for you.
I love this. I watched this after already familiarizing myself with interfaces and dependency injection and lazy initialization. This gave me something to think about when separating interfaces and combining them later for a super interface.
Can you do a video on passing dependencies as interfaces (or native types where it makes sense) to the constructor?
Skill foundry did a video titled: "Dependency Injection in C# ❘ A Hands-On Guide to Boosting Code Flexibility and Testability"
It was great too but I'd like to see an additional twist, throwing exceptions in the getters of the "lazy" properties to cancel the execution of a SQL transaction. Allowing for you to define multiple points of failure where your application SHOULD revert/cancel/undo a SQL transaction that is defined in the entry class. Just an idea (It's also relevant to my current project XD).
I do have a video on dependency injection using interfaces, as well as multiple videos where I use it. I don't have your specific scenario, though.
You are a great teacher....
Thank you.
Another good one Tim.
This reminded me of how the SQL DB tables might need to be split apart (and put together with JOINs).
For noSQL, I would suspect you would use the interface hierarchy to know what keys to expect from the JSON response.
So good good stuff.
I'm glad you enjoyed it.
Thanks for another great lesson. One small detail, I think in IAudioBook interface we miss this property:
string Author { get; set; }
Absolutely fantastic. Many thanks
You are welcome.
Thank you very much for your awesome tutorial. Learnt a lot of things.
Glad it was helpful!
Amazing Explanation!!!
Glad it was helpful!
Nice.
I'm a visual guy, and I think a Class Diagram would be beneficial to see the hierarchy of how all these Interfaces relate. I tried to create one myself, but I can't figure out how to add the Class Designer to the Toolbox. There is nothing in my Toolbox even after I Installed the Class Designer component from the Visual Studio Installer (I'm using VS 2017 Professional). Oh well.
Thanks Tim for you videos, I appreciate them.
I've never been good at the class diagrams. I never seem to get anything useful out of them but I do get a lot of frustration out of them. :-)
Hi your videos very clean and understandable 👌
Great!
Just thinking, In the example mentioned in video, IAudioBook could have been IDigital. In that case IDVD could have implement IDigital and have one extra property Actors solving the DRY issue. Any thoughts?
Great video (even the 3rd time watching). I completely understand what this principal is explaining, however I have recently found myself in a similar situation, but an aspect of the practical implementation is presenting as a challenge. I was curious if you have considered making a video on how to implement some of the more advanced topics.
For your example in this video, lets say you have a database, which stored all your 'List libItems'. Say the requirement is to SELECT * from LibraryItems and put libItems into a data grid. The user would then select a row from the grid and this would show the actual TYPE and its respective "Interface" implementation (such as IBook, IBorrowableBook, IBorrowableDVD...).
The way to do this is probably to store the type name in a property (and put it in the interface). This would also allow you to then cast to that type using a switch statement.
in the first 5 seconds is the question that led me here
Glad to hear it.
Really great videos on SOLID mate.
Thank you!
simply a great video: good example, not too long
Thank you!
Very good film. Thank you.
Thank you!
Hi Tim. Thanks very much for your videos! They are really helping to get my head around the more complex aspects of OOP. Your clarity is greatly appreciated in a field where even the official documentation is often written in a convoluted way that makes it impenetrable to a beginner.
In this video have I understood correctly that it is better to define variables in the application and library classes as the interface rather than the implemented class (eg. IBook book1 = new Book() rather than Book book1 = new Book() )? I struggle to understand how to uncouple classes within a library since they are obviously meant to interact and talk to one another. Does using interfaces in this way serve to loosen the coupling between classes. Perhaps this is more related to dependency inversion?
I just watched the video on dependency inversion and you've answered my question there. Thanks again for such awesome content!
Excellent! I'm glad that was helpful.
HI, Please correct me, if my understanding is wrong with below statement
Assigning the object to the variable of type Interface helps in the scenarios where we can not determine which object comes into the picture dynamically.
In your scenario, if we retrieve borrowable items info from the database . and if we store each record in the list. Means each record describes a thing (DVD or Book or Audio). Then we can assign like below.
List b = GetFromDB();
foreach (var item in b)
{
IBorrowable borrowable = new item();
borrowable.ShipItem();
}
It helps if we don't know the type, but it also helps in that we can store multiple types in the same list. So a list of IBorrowable can have DVDs, Books, and AudioBooks in it.
Great video, but I have a confusion:
In 28:00 you said that we should prefer this:
IBorrowableDVD dvd = new DVD();
instead of this:
DVD dvd = new DVD();
Maybe I missed something, but I don't really get why we should not create the DVD object like in the 2nd option.
Thanks Again Tim!!
14:30 Book Class has things the ReferenceBook does not. Not a huge deal but you would think that a "Book" Class would apply to a "Reference" Book.
23:25 Shouldn't Actors be part of Movie instead of IDVD?
And now I see how I really messed up on a project 10+ years ago and made it super confusing because I was told to use interfaces without understanding how they worked. *sigh* You live, you learn.
I still don't want to go back and touch that code again. *shudder*
At least you know it now so you can do better in your next projects.
It's the sign of a good developer that you can look at your old code and be horrified. If you didn't, it would mean you're not developing yourself.
Hi Tim, at around 28:30 you show why you use IBorrowableDVD by showing how you have access to all the properties which you don't if you implement only IBorrowable or IDVD.
My question is, why simply not inherit from a DVD class (DVD that implements IDVD and IBorrowable, the same as IBorrowableDVD interface) and have access to the same properties? Is it because the video is about ISP, or there's more?
Personally, I don't see a great use of interfaces that ONLY merge other interfaces and not bring additional stuff into the contract. Thank you for everything you're doing!
edit: just remembered another reason for it: unit testing, but again, since it only merges two interfaces, shouldn't testing those two "base" interfaces cover everything?
Please make a video on how to read built-in classes. A few days ago I was trying to see from the controller, how it returns OK/BadRequest as IACtionResult, I knew they implemented IActionResult interface but after opening the class I could not understand how they are working actually. Too difficult to understand as a beginner/intermediate-level developer.
Quick question, why are we not extending ILibraryItem to IBorrowable, they are also a Library item as I understand. Also IBorrowable would not have to have a separate property as a libraryId and Title, as it would simply have the ILibraryItem properties
Hello Tim! There is something i don't get. For example: I have an IPrinter interface with the method Print() , but there are some printers with the capability of sending e-mail's, so i have the IMailPrinter interface with the method SendMail(). Then , i have a software which in case the printer has the capability, has to send an e-mail after making an invoice. So In that case, the client has the IPrinter dependency, the problem is that at the moment of making the invoice, the client has to ask if that dependency has the capability to make one or other action. So, at the end, there is a need to have one or multiple if statements on the UI/Client side, like this : " if (printer is IMailPrinter) { ((IMailPrinter)printer).SendMail()}" and that's not nice. In this case, how can i solve the problem?
You could combine two interfaces so they would have both methods available when appropriate. Otherwise, you will need to do some casting. You can make that easier, though, by doing as follows:
if (printer is IMailPrinter p) { p.SendMail();}
Thank you very much Sir.
You are welcome.
My question would be how does this relate to database tables. Say we have a table LibraryItems that has all the needed columns for a library item, and an int column that maps to an Enum to show which type of LibraryItem it is, (DVD, Book, AudioBook, etc). We then have a Model that has matching properties to the DB cols. When we query that table and map it to that matching (entity) model, would that (entity) model for each type, then be mapped to their respective DVD, Book, AudioBook models?
Thanks a lot Tim for the wonderful job again. One question please: it seems we should combine interfaces first then create class to implement the single combined interface, could we sometimes create a class to implement 2 interfaces? Please advise. Thanks again.
Sure, a class can implement as many interfaces as you need. You can only inherit from one class but you can have multiple interfaces against one class.
Wow, so much interfaces. I think I can see generally the use of that in making code, but as this example really shows, to make a good Library apps it would need much consulting with Librarians. Maybe I'm wrong, but for starts I think they first divide Digital an NonDigital publications, and so on, and so on. Whit out that code is just a mess using interfaces or not. Thanks for vids!
That's the key with any application - consult with people who actually use the software. Not just management - the person who has to enter data is even more vital. They can usually tell you the pain points and they can shoot down your "good ideas" if they aren't practical.
Great video Tim. Thanks
You are welcome.
I like this SOLID series. However, one question arised: Does it not make sense to have a base class "LibraryItem" instead of the interface - all the books, DVDs and so on are library items, as you mentioned - or did I miss something?
It can make sense to have a base class LibraryItem but not always. If you used that as the base class, that means you can't have a different base class for some items. In our case, that is probably fine but it is something to consider.
@@IAmTimCorey Hello Corey, could you please explain what you meant by having a base LibraryItem class means "you can't have a different base class for some items"?
Hey, great video! However, I have a question, can't we create another interface called IPlayable that implements the property RuntimeInMinutes? That way we don't have to repeat ourselves.
That's the comment I was looking for, right there! My idea was "IPlayableMedia" ... same thing. Right now it doesn't really matter that much for the sake of this one property, but think about the future, new features and scale. In the future an application might want to show a user how much time they've spent playing certain media files or have a system to remember where they left off when they reopen it. The IPlayableMedia interface could end up having more properties like SizeOnDisk, CurrentPosition, UserRating, IsFavorite, etc. The application could operate on these objects through the interface without caring if it's audio vs video: they actually have a great deal in common as media and you'll see similar concepts if you pay attention to software for Windows.
Thanks Tim, that was very good, and that resolved my problem in BIG issue.
Awesome! I'm glad it solved a problem for you.
Great tutorial.
After going through your LSP and ISP videos of SOLID Principle, i got one doubt. Doubt is in LSP and ISP both, you are segregating into interfaces then implementing those interface into classes. So how these both are different to each other. Please explain.
They both use interfaces but all of the SOLID principles do in practice. The focus of LSP is how objects relate to their parents. The focus of ISP is on how interfaces are developed and used. The focus is on different parts of OOP between the two.
As usual top notch content!
Thank you!
Once again an excellent tutorial : it's even understandable for an absolute C# rookie :). One question though : are those SOLID principles integrated in any of your courses ? I mean by this do you propose any (payable) course integrating "How to build a C# (or any other fully OO language for that matter) implementing the SOLID principles from the ground up ?
Yes and yes. At IAmTimCorey.com, for the more advanced user, we build the TimCo application from Requirements to deployment and also incorporate enhancement cycle. SOLID is used. The UA-cam version of TimCo can be found here also - ua-cam.com/video/Xtt6mS0p2_c/v-deo.html
The library item doesn't need any circulation data.
Circulation is a collection that references library items that are not shelved.
Circulation Policy determines when and how the items circulate.
Thanks for sharing you perspective.
Thank you a lot. Keep doing what you're doing, you're good at it.
Thank you!
Great video. My only question would be how to make an ObservableObject using IMapTypes. When I try
ObservableObject booklist = new ObservableCollection
doesn't work, but this seems to:
public async Task CreateMapList()
{
return new ObservableCollection
{
new MapTypes {Id = 0, MapTypeString = AppResources.Hybrid},
new MapTypes {Id = 1, MapTypeString = AppResources.Satellite},
new MapTypes {Id = 2, MapTypeString = AppResources.Street},
new MapTypes {Id = 3, MapTypeString = AppResources.Terrain}
};
}
Please explain. Thanks
The difference between the two is that in your second example, you are creating an ObservableCollection instead of ObservableCollection. When you instantiated the OC in the first example, you changed to the concrete type MapTypes. That is more restrictive than the declaration was, which doesn't work. You could, however, still assign MapTypes to the more loosely defined ObservableCollection.
Great lesson, really clear and detailed. I'll have to start looking at doing more interfaces in future :) Looking forward to the last one of the SOLID set!
Thanks!
Hi Tim, Thanks for making this video. I have one question though. Why did you create another interface, IBorrowableBook that joins together IBorrowable and IBook instead of just making the book class implement both interfaces? What is the purpose behind that?
That way you can access the properties of both interfaces at once without needing to cast from one to the other.
Thank you Tim for the video. I've got a question about this.
Would it be a good idea to have the IBorrowable interface instead be an abstract class (Borrowable.cs) so that we could help us not repeat ourselves (DRY ?) with properties such as Borrower, BorrowedDate, or the three methods CheckIn, CheckOut, GetDueDate in classes like AudioBook, Book or DVD ? I am just not sure 100% when to use an interface and when to do simple class inheritance with a base abstract class (like we did in the LSP video with BaseEmployee class). I would love to find new system-design exercises like this where I could make these decisions and get better at doing so.
Thank you again !
The problem with that is that the elements that would need the Borrowable abstract class are not related tightly enough. Their only real relationship is that they can all be borrowed. This is not the way to use inheritance. It locks you in and causes problems.
@@IAmTimCorey I'm guessing one way to identify this Is to ask "Is B an A object ?" Like you said in this and previous videos ... Books, AudioBooks, DVDs "can be borrowed" (characteristics) but they "ARE NOT A ..." Borrowable object themselves unlike an Employee that IS A Person. Thank you Tim.
great teacher ...
Thanks!
Great video class partner!
Thank you!
Hi! I am a newbie in C# and have some questions :D 1. If i wanna use field, property or function of some class i should do it only by interface? 2. There is a reason to not make base class BaseLibraryItem wchich have only LibraryID? 3. I would really love to see a big structure of for example OrganicLife that have humans, lions, plants, trees, bacteria and fungus - off course within reason ^^.
You can have properties or methods that are not specified in an interface. You just need to cast the type to the given class to use them. As for the base class, that is a possibility but you do need to exercise caution with base classes. They are used to indicate a relationship, not just a code-sharing mechanism. In this case, there is a relationship. However, the other thing to be careful of is that you only get one base class. So, if you decide that LibraryItem is what you want to go with, you can't have your DVD class inherit from the Movie base class.
Really appriciate for your great video, thank you bro.
You are welcome.
Great video, but I have one question: if we initialize a variable as IBook or IBorrowableBook - do we get different objects then, with different set of properties and methods?
Nope. The object is the same but we have access to only what the contract says unless you cast it.
Thanks Tim for such a crystal clear explanation and also making me understand why to have a combination interface (IBoorowableBook, IborrowableDVD..).
Also the example which was taken for this explanation was very much relevant and easy to relate to the realtime projects
You are most welcome. Thanks for watching.
Valeu!
Thank you!
Another great video! Thank you!
You are most welcome. Thanks for watching.
THANK YOU SO MUCH!
You're welcome!
What are the pros/cons of creating an empty IBorrowableDVD interface that implements IDVD and IBorrowable vs just implementing those same interfaces directly in the DVD class and then creating instances of the DVD class with the Class type itself like:
class DVD : IDVD, IBorrowable
...
DVD dvd = new DVD();
I tested it in code and its seems functionally the same.
Do you lose some flexibility with an object that is typed by the class instead of the interface that it implements?
Okay, nm...2 minutes in the the Dependency Inversion video and I think i'm starting to understand.
I'm glad you are figuring it out.
Hi Tim,
Again, great video. One question: Why do you put IBorrowableDVD and not DVD so reference to the interface and not the class.
IBorrowableDVD dvd = new DVD();
DVD dvd = new DVD();
You have the same dropdown intelli.
Thanks,
Peter
First, to show that you can. Second, you don't have to put a DVD instance in an IBorrowableDVD. If another class used that same interface, you could put that instance in the dvd variable instead.
@@IAmTimCorey yes, thanks, got it.
Hi Tim, Awesome video need one help could you please create one video for GetHashCode() , and please tell me exact difference between Extension mathod and static method. Thanks in advance
Thanks for the suggestions. I’ll add them to the list.
How did I miss this video? UA-cam is sometimes really had at suggesting videos from people I am subscribed. This is great for getting you thinking on a different level. Great video! What course or other videos do you have that further explains this? I get this but I would love more examples of you have them.
I do have a playlist that includes all of SOLID and DRY: ua-cam.com/play/PLLWMQd6PeGY3ob0Ga6vn1czFZfW6e-FLr.html I also use these topics in my full projects (TimCo Retail Manager, for example).
Firstly, thank you for the great content. I do have a question based on some digging I did on "empty interfaces" (or more specifically, the issue with accessing members from both IDVD and IBorrowable without the empty IBorrowableDVD interface). Couldn't we solve that issue by using a generic class/method with type constraints for IDVD and IBorrowable? This would serve the same purpose while also enforcing code consistency, since classes could otherwise implement IDVD + IBorrowable or just IBorrowableDVD.
I don’t see the problem you are trying to solve here. A “generic” class to do what IBorrowableDVD does would be a base class. You can often use base classes to replace interfaces but that then implies a strong relationship in all of the children that might not be present in order to replace something that works great.
Thanks tim for this course, do you have the sourcecode in python also regarding the same project.
No, sorry. Only C# code.
And how can we see the output of this code like the generated library after all the addition of books, audiobooks, dvd files etc. in visual studio