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.
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.
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!
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!
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!
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).
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.
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.
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
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.
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.
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 :)..
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
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?
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 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?
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
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. :-)
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 TH-cam version of TimCo can be found here also - th-cam.com/video/Xtt6mS0p2_c/w-d-xo.html
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.
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.
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, 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?
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"?
Have watched a lot of your videos and they've been really helpful! Quick question, if one has to cast in a program, does that make it tightly coupled to the class it is casting to? What would you do if you taking a list of library items and count of DVDs ? Also , I've noticed that you make interfaces for majority of your classes , so is it advisable to rather have a ton of interfaces that dictate the expected behavior in a class to ensure loose coupling?
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.
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.
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.
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 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.
Great video as always Tim, thanks a lot!! I only have one question which is that I can't quite understand the difference between LSP and ISP, they both look the same to me. In the end, they both focus on grouping the features into interfaces according to necessity between classes. What's the actual logical difference between them?
LSP focuses on ensuring subclasses can be replaced by base classes without breaking an application or changing the intended behavior in unexpected ways. ISP focuses on preventing classes from becoming bloated with unused methods and properties because they implement interface(s) that do too much.
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.
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?
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!
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.
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
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.
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?
How did I miss this video? TH-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: th-cam.com/play/PLLWMQd6PeGY3ob0Ga6vn1czFZfW6e-FLr.html I also use these topics in my full projects (TimCo Retail Manager, for example).
Okay, I understand your explanation for IDVD, but couldn't you use the class type as an indicator for what kind of media for the movie movie? or in general, would having "DVD.cs" named as "Movie.cs" actually be better, and let the different interfaces determine the media type for the movie?
Class names indicate types. Interfaces indicate functionality. So we wouldn't want to name our class "Movie" because a DVD movie is different than a BluRay movie (different format at the least).
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 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?
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.
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();}
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.
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 ..
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.
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.
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.
Hello Tim Corey, Great video series, thank you for making them. Makes this stuff much clearer to me. Did I miss something, or should the IAudioBook Interface have an author property? Greetings Sabrina
@@IAmTimCorey but placing the Author property in the IAudioBook interface would kinda violate the DRY principle because it is already present in the IBook interface and it is very related would't it ?
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.
Nice tutorial Tim! I've been playing a bit with this project and i have a question, isn't better to create a Borrow class and make every LibraryItem class inherit from it, and then create an IBorrowable and INotBorrowable to filter data? So then you can create new items like this INotBorrowable dvd = new DVD; or IBorrowable dvd = new DVD;
You want to be really careful with inheritance. Remember that it isn't code-sharing. It is about relationships. If you made everything inherit from Borrow but some were not borrowable, that doesn't make sense. Also, a DVD is not a book. While they have similarities in a library, they are two different things.
In your videos, you say that there is a link to the blog post about the subject, but all I ever get is a form to enter my email address and get the source code. What happened to the blog?
Isn't a bad thing to name folder and a class inside that folder with same name, because then the namespace conflicts with class, could that lead to reference issues?! Could you make a video about your folder structure naming conventions, and solution structure guidelines, for naming different libraries and projects. Btw, great series. Huge fan :)
Ideally you would name the folders something a bit different than the class because of that confusion but the confusion is mostly on our end, not the compiler's end. But yes, you are correct that we should avoid it. As far as creating a video on naming conventions and solution layouts, I could probably do that. I'll add it to the list.
Yeah, had this error and was boggling my mind because the output of the error just says that an object with the class name already exists - never mind that it's a folder, lol.
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. 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.
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*
I know that video is getting old, but thanks alot Tim! I got a question, how would you relate this against a data base, I mean, would you have one item "LibraryItem" and "LibraryItemId" would be their key? Maybe to much too ask, i'd appriciate a video relating Repository pattern with SOLID? :D
Because this is a demo, I would probably rework it but to specifically answer your question, yes, the LibraryItem would probably be a database entry and the ID would be the primary key.
Yes, but you can only access the members of an interface that you are using so if you have an IBook variable, even if it is borrowable, you cannot access those members without casting it to IBorrowable. By creating a new interface that has both, we can access all of the properties and methods of both.
Thanks for the clarification! I noticed you went more into detail on that subject when you were doing the DVD. Spoke too soon! 😅 Thanks for the superb series of SOLID videos!
![일상 속 기분 좋음 [Proto disco meme]](http://i.ytimg.com/vi/DwmEIaZ7XGQ/mqdefault.jpg)
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
By far the best video on SOLID! Thank you so much for posting it!!!
I am glad you enjoyed it.
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.
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.
I finally understood Interfaces thanks to your videos. Thanks Tim !
Excellent!
IMO, the best video I've come across explaining and demonstrating the application of SOLID principles. Thanks!
You are most welcome. Thanks for watching.
Listening to Tim say "borrowable" so many times has made my day for some reason! Joking aside, though, thank you for the great video!
😂
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.
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 TH-cam.
Thank you!
Thank you for making this design pattern series. It's given me more confidence in planning out my code.
You're very welcome!
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).
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.
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!
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.
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.
Best series about SOLID. thank you so much for explan all principle
You're very welcome!
Thank you Mr. Corey, another great video, I only wish I watched this video 5 years ago.
You are welcome.
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.
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.
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.
Wow, I finally understand why interfaces are so powerful! Thank you!
Happy to help!
Thank you very much.
A SOLID precise explanation on The SOLID principles.
Glad it was helpful!
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!
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
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 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!
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
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?
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 all the explanations, it will change my coding pattern.
Great!
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.
This is great. It belongs in a playlist.
It is in one: th-cam.com/play/PLLWMQd6PeGY3ob0Ga6vn1czFZfW6e-FLr.html
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?
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
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.
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 TH-cam version of TimCo can be found here also - th-cam.com/video/Xtt6mS0p2_c/w-d-xo.html
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. :-)
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.
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.
Thank you so much Tim. I'm learning a lot from you.
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.
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.
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"?
Have watched a lot of your videos and they've been really helpful!
Quick question, if one has to cast in a program, does that make it tightly coupled to the class it is casting to? What would you do if you taking a list of library items and count of DVDs ?
Also , I've noticed that you make interfaces for majority of your classes , so is it advisable to rather have a ton of interfaces that dictate the expected behavior in a class to ensure loose coupling?
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
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 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.
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, the source codes you upload are they before the changes in this video or after?
I believe I include both in the zip file.
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!
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.
Thanks for another great lesson. One small detail, I think in IAudioBook interface we miss this property:
string Author { get; set; }
Explained in great detail... nicely done.
Thank you!
Great video as always Tim, thanks a lot!!
I only have one question which is that I can't quite understand the difference between LSP and ISP, they both look the same to me. In the end, they both focus on grouping the features into interfaces according to necessity between classes. What's the actual logical difference between them?
LSP focuses on ensuring subclasses can be replaced by base classes without breaking an application or changing the intended behavior in unexpected ways. ISP focuses on preventing classes from becoming bloated with unused methods and properties because they implement interface(s) that do too much.
Simply awsome ('Zabardast' in URDU language)
Thanks!
Thanks, Tim. Super useful tutorial.
You are welcome.
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.
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?
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!
Combining interfaces using another interface is so simple but so genius.
I am glad it 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.
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.
Just solved my interface problem. Thanks.
Glad I could help
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.
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?
How did I miss this video? TH-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: th-cam.com/play/PLLWMQd6PeGY3ob0Ga6vn1czFZfW6e-FLr.html I also use these topics in my full projects (TimCo Retail Manager, for example).
Okay, I understand your explanation for IDVD, but couldn't you use the class type as an indicator for what kind of media for the movie movie? or in general, would having "DVD.cs" named as "Movie.cs" actually be better, and let the different interfaces determine the media type for the movie?
Class names indicate types. Interfaces indicate functionality. So we wouldn't want to name our class "Movie" because a DVD movie is different than a BluRay movie (different format at the least).
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
Thank you very much for your awesome tutorial. Learnt a lot of things.
Glad it was helpful!
I didn't get the idea for IBorrowableDVD. Aren't all DVDs borrowable? Can' we just make IDVD has the members for borrowing since every dvd is borrowed
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.
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.
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();}
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.
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 ..
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.
Thanks Tim, that was very good, and that resolved my problem in BIG issue.
Awesome! I'm glad it solved a problem for 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.
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.
Hello Tim Corey,
Great video series, thank you for making them.
Makes this stuff much clearer to me.
Did I miss something, or should the IAudioBook Interface have an author property?
Greetings
Sabrina
Yep, that would probably be a good thing to add to it.
@@IAmTimCorey but placing the Author property in the IAudioBook interface would kinda violate the DRY principle because it is already present in the IBook interface and it is very related would't it ?
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.
Nice tutorial Tim! I've been playing a bit with this project and i have a question, isn't better to create a Borrow class and make every LibraryItem class inherit from it, and then create an IBorrowable and INotBorrowable to filter data? So then you can create new items like this INotBorrowable dvd = new DVD; or IBorrowable dvd = new DVD;
You want to be really careful with inheritance. Remember that it isn't code-sharing. It is about relationships. If you made everything inherit from Borrow but some were not borrowable, that doesn't make sense. Also, a DVD is not a book. While they have similarities in a library, they are two different things.
Thank you a lot. Keep doing what you're doing, you're good at it.
Thank you!
Hi your videos very clean and understandable 👌
Great!
In your videos, you say that there is a link to the blog post about the subject, but all I ever get is a form to enter my email address and get the source code. What happened to the blog?
Good catch. I added this Blog post to the video notes - www.iamtimcorey.com/blog/36001/solid-in-csharp
simply a great video: good example, not too long
Thank you!
Isn't a bad thing to name folder and a class inside that folder with same name, because then the namespace conflicts with class, could that lead to reference issues?!
Could you make a video about your folder structure naming conventions, and solution structure guidelines, for naming different libraries and projects.
Btw, great series. Huge fan :)
Ideally you would name the folders something a bit different than the class because of that confusion but the confusion is mostly on our end, not the compiler's end. But yes, you are correct that we should avoid it. As far as creating a video on naming conventions and solution layouts, I could probably do that. I'll add it to the list.
Thanks, and keep up the good work :)
Yeah, had this error and was boggling my mind because the output of the error just says that an object with the class name already exists - never mind that it's a folder, lol.
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. 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.
in the first 5 seconds is the question that led me here
Glad to hear it.
You are a great teacher....
Thank you.
Really great videos on SOLID mate.
Thank you!
Absolutely fantastic. Many thanks
You are welcome.
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.
I know that video is getting old, but thanks alot Tim! I got a question, how would you relate this against a data base, I mean, would you have one item "LibraryItem" and "LibraryItemId" would be their key? Maybe to much too ask, i'd appriciate a video relating Repository pattern with SOLID? :D
Because this is a demo, I would probably rework it but to specifically answer your question, yes, the LibraryItem would probably be a database entry and the ID would be the primary key.
@@IAmTimCorey but, it Will be only on table? And this Will have all the fields on it? Either for "borrowable" and not borrowable
Question: couldn't Book.cs implement IBook, IBorrowable directly, instead of making another interface of IBorrowableBook?
Yes, but you can only access the members of an interface that you are using so if you have an IBook variable, even if it is borrowable, you cannot access those members without casting it to IBorrowable. By creating a new interface that has both, we can access all of the properties and methods of both.
Thanks for the clarification! I noticed you went more into detail on that subject when you were doing the DVD. Spoke too soon! 😅 Thanks for the superb series of SOLID videos!
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