Probably the best series about SOLID TH-cam can offer! Although I write code in Java, it doesn't matter because it is perfectly explained. Thanks for this!
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. TH-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.
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.
Thank you Tim, among TH-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).
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!
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
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.
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.
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 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).
@@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.
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.
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
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).
22:30 : What do you think about this? IMediaItem : ILibraryItem { int RuntimeInMinutes { get; set ;} } Then anything in the future, even digital movies or anything else could implement... ? A little granular for this example, probably, but maybe there could be situations where grouping anything that is a "media item" may make sense?
At 27:15, wouldn't assigning the variable type to DVD technically give us access to both interface properties? When would we want to use an interface as the variable type instead of the actual class? I have this question everytime i write code with interfaces. Why could not we use like DVD d = new DVD. Then d will have all properties of multiple interfaces ri8?
Yes, using the full type gives you access to everything. However, you cannot use another object that implements IBorrowable to the variable, only a DVD. Using the interface allows you to use any class that implements that interface. That means you can more easily unit test your application and you can be flexible on what you are borrowing (DVD, BluRay, Book, etc.)
@@IAmTimCorey Means it will be useful if we dont know what objects will come dynamically ri8? Can you elaborate this with example?I mean a real time scenario where we can not determine which object comes ..
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.
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?
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.
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?
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
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.
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!
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.
21:50 Apples and Oranges do have something in common, they are both fruit! We could think of an AudioBook and Movie have something in common, as they both have a runtime, we could think of an interface like IPlayable. And anything that can be played like DVD, Blu-ray, MP3 can all implement IPlayable. Interfaces do describe behavior as well so it makes sense
Yes, they are both fruit but how does that impact inheritance? Just because two things are somewhat related does not mean that they should be in an inheritance relationship. The "is a" relationship test (apple is a fruit, orange is a fruit) is only really the first step. Then you need to identify if that relationship adds any value. That's what I was trying to communicate here. As for Audiobook and Movie, yes, you can figure out some type of relationship (entertainment? storyitem? Not sure what you would even call the base relationship.) but that locks you in a corner. If you say that the relationship is based upon both having runtime then you cannot add a book, yet an audiobook and a book have a LOT more in common (they can actually be the same thing in different formats). That's why you can figure out relationships between items, but that isn't the only criteria. You need to figure out if the relationship makes sense, what items it excludes that might become a problem, and if it really adds value to have the relationship.
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.
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?
Thank you for the great video! I am just getting familiar with interfaces and have some newbie questions. At 27:15, wouldn't assigning the variable type to DVD technically give us access to both interface properties? When would we want to use an interface as the variable type instead of the actual class? Are we preparing for when multiple classes will use the IBorrowableDVD interface in the future? Thank you. edit : Just got back from watching the dependency inversion video where interfaces are used to loosely couple the project. I think I understand it a little bit better now.
27:55 "So the only way to get all that information is to cast it to the actual implementation type, which is the type DVD, not really what we want to do"...why's that 'not really wanna do'? What are risks/cons of casting to the actual implementation type?
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?
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"?
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
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*
@@IAmTimCorey after watch the your SOLID series a few times, I succesfully rebuild my work web api project using Dependency Inversion, Dependency Injection along with unit testings! great stuff! thanks so much!
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.
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.
Hi Tim, great videos by the way. Question @17:59 AudioBook : IBorrowableAuioBook can this not be AudioBook : IAudioBook, IBorrowable? instead of creating an extra interface IBorrowableAudioBook. You answered my question already @26:47. Thank you😃
Hi @IAmTimCorey, very cool video, good job! I have a question. I had to create a screen to display any kind of attachment, so different attachments are handled in different ways, what comes in is the raw byte and the tipe. So what I did, I created a Interface IAttachment, that has Create, Load and Release. In the creation of the screen, it receive an IAttachment, then when the application need to display something it calls the screen that call the Create, when the screen will be showed it call the Load, and when the screen is closed it call the Release. So far so good. The thing is, only some types require the Release method, other types don't. But how would I keep clean and call the Release from the screen if I broke down the main interface without the Release, the Variable of IAttachment wouldn't have the .Release avaliabe. Is the Interface type check the only way to do it? So in the Close I check if the Variable implements the "IReleseable", cast and call the Release, or there is a more "Elegant" way of doing it?.
I would probably create a second interface for IRelease and then do an interface check. An alternate way to do this would be to turn IAttachment into an abstract class instead. Then create placeholders for Create and Load but create a full method for Release that does nothing (or just logs that it was called). Then you could call Release every time. It isn't as elegant but it is simpler.
Yeh, I did the interface type check cause it was "simpler", I was just wondering if there were a "legit" way of doing it. As the main goal of doing this is to avoid future problems. By the way, Thanks for reply, I do appreciate that.
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?
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.
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
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.
SOLID videos, sir. Question: I've been programming for well over a decade now (self taught / mentored) I have a lot of old, poor habits. One of them is just sitting down and creating spaghetti for hours straight. I'll forget that a programming language has some cool feature, and write some elaborate hack to achieve a result. (learned programming with C++03 so...yeah) How do you effectively change your brain to subconsciously use these principles while in a complete flow state? As soon as the flow state starts, its all the deeply ingrained habits that come out.
Practice and planning. It takes that constant repetition of better habits to break bad ones. And planning before you build helps direct your development process and ensure you stay on the right track.
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?
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 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.
By far the best video on SOLID! Thank you so much for posting it!!!
I am glad you enjoyed it.
Probably the best series about SOLID TH-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.
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. TH-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
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!
Listening to Tim say "borrowable" so many times has made my day for some reason! Joking aside, though, thank you for the great video!
😂
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!
In my opinion Tim’s videos on SOLID are hands down the best ones on TH-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!
Thank you Tim, among TH-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).
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!
Valeu!
Thank you!
Best series about SOLID. thank you so much for explan all principle
You're very welcome!
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.
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.
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 very much.
A SOLID precise explanation on The SOLID principles.
Glad it was helpful!
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.
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.
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).
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!
Wow, I finally understand why interfaces are so powerful! Thank you!
Happy to help!
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.
great guide, even it's in c# which i don't know at all its very easy understandable
I'm glad!
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.
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
This is great. It belongs in a playlist.
It is in one: th-cam.com/play/PLLWMQd6PeGY3ob0Ga6vn1czFZfW6e-FLr.html
Simply awsome ('Zabardast' in URDU language)
Thanks!
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
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!
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.
Thank you for all the explanations, it will change my coding pattern.
Great!
Explained in great detail... nicely done.
Thank you!
Thank you so much Tim. I'm learning a lot from you.
You are welcome.
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.
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, Tim. Super useful tutorial.
You are welcome.
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.
22:30 : What do you think about this?
IMediaItem : ILibraryItem { int RuntimeInMinutes { get; set ;} }
Then anything in the future, even digital movies or anything else could implement... ? A little granular for this example, probably, but maybe there could be situations where grouping anything that is a "media item" may make sense?
That might work.
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.
At 27:15, wouldn't assigning the variable type to DVD technically give us access to both interface properties?
When would we want to use an interface as the variable type instead of the actual class?
I have this question everytime i write code with interfaces. Why could not we use like DVD d = new DVD. Then d will have all properties of multiple interfaces ri8?
Yes, using the full type gives you access to everything. However, you cannot use another object that implements IBorrowable to the variable, only a DVD. Using the interface allows you to use any class that implements that interface. That means you can more easily unit test your application and you can be flexible on what you are borrowing (DVD, BluRay, Book, etc.)
@@IAmTimCorey Means it will be useful if we dont know what objects will come dynamically ri8? Can you elaborate this with example?I mean a real time scenario where we can not determine which object comes ..
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.
Just solved my interface problem. Thanks.
Glad I could help
Hi your videos very clean and understandable 👌
Great!
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.
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?
Really great videos on SOLID mate.
Thank you!
Thank you very much for your awesome tutorial. Learnt a lot of things.
Glad it was helpful!
simply a great video: good example, not too long
Thank you!
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. :-)
Absolutely fantastic. Many thanks
You are welcome.
Amazing Explanation!!!
Glad it was helpful!
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?
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
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.
Thank you a lot. Keep doing what you're doing, you're good at it.
Thank you!
You are a great teacher....
Thank you.
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!
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.
Great video class partner!
Thank you!
Thanks Tim, that was very good, and that resolved my problem in BIG issue.
Awesome! I'm glad it solved a problem for you.
Combining interfaces using another interface is so simple but so genius.
I am glad it was helpful.
21:50 Apples and Oranges do have something in common, they are both fruit! We could think of an AudioBook and Movie have something in common, as they both have a runtime, we could think of an interface like IPlayable. And anything that can be played like DVD, Blu-ray, MP3 can all implement IPlayable. Interfaces do describe behavior as well so it makes sense
Yes, they are both fruit but how does that impact inheritance? Just because two things are somewhat related does not mean that they should be in an inheritance relationship. The "is a" relationship test (apple is a fruit, orange is a fruit) is only really the first step. Then you need to identify if that relationship adds any value. That's what I was trying to communicate here. As for Audiobook and Movie, yes, you can figure out some type of relationship (entertainment? storyitem? Not sure what you would even call the base relationship.) but that locks you in a corner. If you say that the relationship is based upon both having runtime then you cannot add a book, yet an audiobook and a book have a LOT more in common (they can actually be the same thing in different formats). That's why you can figure out relationships between items, but that isn't the only criteria. You need to figure out if the relationship makes sense, what items it excludes that might become a problem, and if it really adds value to have the relationship.
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.
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.
Thank you for the great video!
I am just getting familiar with interfaces and have some newbie questions.
At 27:15, wouldn't assigning the variable type to DVD technically give us access to both interface properties?
When would we want to use an interface as the variable type instead of the actual class?
Are we preparing for when multiple classes will use the IBorrowableDVD interface in the future?
Thank you.
edit : Just got back from watching the dependency inversion video where interfaces are used to loosely couple the project. I think I understand it a little bit better now.
Glad you figured it out.
Really appriciate for your great video, thank you bro.
You are welcome.
27:55 "So the only way to get all that information is to cast it to the actual implementation type, which is the type DVD, not really what we want to do"...why's that 'not really wanna do'? What are risks/cons of casting to the actual implementation type?
You need to know about the type. That tightly couples the class again (or it can, at least).
Thanks for another great lesson. One small detail, I think in IAudioBook interface we miss this property:
string Author { get; set; }
Great video Tim. Thanks
You are 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.
As usual top notch content!
Thank you!
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"?
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.
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.
Very good film. Thank you.
Thank you!
this is the third time I watched this video!
I am glad it has been helpful.
@@IAmTimCorey after watch the your SOLID series a few times, I succesfully rebuild my work web api project using Dependency Inversion, Dependency Injection along with unit testings! great stuff! thanks so much!
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.
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.
Hi Tim, great videos by the way. Question @17:59 AudioBook : IBorrowableAuioBook can this not be AudioBook : IAudioBook, IBorrowable? instead of creating an extra interface IBorrowableAudioBook. You answered my question already @26:47. Thank you😃
You are welcome.
Hi @IAmTimCorey, very cool video, good job!
I have a question. I had to create a screen to display any kind of attachment, so different attachments are handled in different ways, what comes in is the raw byte and the tipe.
So what I did, I created a Interface IAttachment, that has Create, Load and Release.
In the creation of the screen, it receive an IAttachment, then when the application need to display something it calls the screen that call the Create, when the screen will be showed it call the Load, and when the screen is closed it call the Release. So far so good.
The thing is, only some types require the Release method, other types don't. But how would I keep clean and call the Release from the screen if I broke down the main interface without the Release, the Variable of IAttachment wouldn't have the .Release avaliabe.
Is the Interface type check the only way to do it? So in the Close I check if the Variable implements the "IReleseable", cast and call the Release, or there is a more "Elegant" way of doing it?.
I would probably create a second interface for IRelease and then do an interface check. An alternate way to do this would be to turn IAttachment into an abstract class instead. Then create placeholders for Create and Load but create a full method for Release that does nothing (or just logs that it was called). Then you could call Release every time. It isn't as elegant but it is simpler.
Yeh, I did the interface type check cause it was "simpler", I was just wondering if there were a "legit" way of doing it. As the main goal of doing this is to avoid future problems.
By the way, Thanks for reply, I do appreciate that.
Another great video! Thank you!
You are most welcome. Thanks for watching.
in the first 5 seconds is the question that led me here
Glad to hear it.
Nice video. Awesome job
Thanks!
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?
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.
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
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.
SOLID videos, sir.
Question:
I've been programming for well over a decade now (self taught / mentored)
I have a lot of old, poor habits. One of them is just sitting down and creating spaghetti for hours straight. I'll forget that a programming language has some cool feature, and write some elaborate hack to achieve a result. (learned programming with C++03 so...yeah)
How do you effectively change your brain to subconsciously use these principles while in a complete flow state? As soon as the flow state starts, its all the deeply ingrained habits that come out.
Practice and planning. It takes that constant repetition of better habits to break bad ones. And planning before you build helps direct your development process and ensure you stay on the right track.
IAmTimCorey Thank you.
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.
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.
10:15 Actually it extends not inherits its not a big deal, but good explanation overall ^^
Yeah, I switched that one up.
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.
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