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. RU-vid 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 RU-vid 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!
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.
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 Tim, among RU-vid 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.
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
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.
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.
@@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.
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
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.
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*
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. :-)
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 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.
The library item doesn't need any circulation data. Circulation is a collection that references library items that are not shelved. Circulation Policy determines when and how the items circulate.
Code design is important. It's why I became a code designer. As a vanity, I like to code pretending that people will see it and use it with extreme ease, but I have little intention of that. I code to make stuff. Honestly, what authority in this universe actually cares and goes around judging our code with their fabricated principles? Some points are solid (not a pun), the rest are loose.
I've also noticed that too many tutorials assume we are only making API for everyone else, rather than building for ourselves. Weird. And my code sparkles. I'm always going back to use it, and I'm the one that finds things to improve, without any code politics.
Others make a good point about => Spaghetti Code. And a great way to create that is to split classes up into new classes which isn't needed. So, what in System.Console would you move to another class, and what would it's less appropriate name be?
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?
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
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.
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?
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.
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.
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?
Hi Corey, I think the interface IAudio should have the Author property because the ILibraryItem interface did not have it but the IBook have and a Book is not a Audio the IAudio interface should have two properties the RuntimeInMinutes and the Author and inheriting from the ILibraryItem interface. Thanks for the Videos
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.
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?
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 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
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.
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.
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 ..
@@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!
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?
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
One could argue that both Audio Books and DVDs are related as they are both recorded media. They would both have runtime minutes, as well as encoding and format (specifically for digitally recorded media). Audio Books also have Actors, by the way. The person who's reading the book is an actor. There are several similarities between audio books and DVDs (and VHS, BluRay, CD, etc.) if you think about it. In your example, we'd have to duplicate those attributes across every type of recorded media. DRY.
Similarities aren't the same as being the same thing. Technically a person who reads an audiobook is an actor but it would not be listed as such on the case. It would be listed as the narrator. DVDs typically do not have narrators listed. Be careful not to force similarities. If people do not expect things in the same format, it will cause confusion. DRY can be misused.
@@IAmTimCorey For the sake of argument, let's take Actor out (even though Narrators are also known as "Voice Actors"). You still have three other attributes (running time, encoding, format) that would be duped across all forms of digital media. There are probably other attributes if you get into the technical weeds. Keep in mind that audio books were originally (and probably still are in some cases) released on CDs. CDs require encoding and format metadata. Not all CDs can be played in the car, for example, due to the type of encoding. In the case of the library example, Audio Books would probably be CDs. Wouldn't you say that a CD is "close enough" to a DVD that they share certain aspects? What's the magic number of attributes needed before IRecordedMedia (or something *similar*) would be useful in this scenario?
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.
I would argue that Runtime on a temporal medium whether it is Audio or visual, mp3 CD audio book, Vinyl, CD, DVD, cinefilm, cassette, VHS, Laserdisc or wax cylinder is a common property and should be an interface. Using the logic you gave you could argue that a DVD and book are nothing alike so shouldn't have a borrowable interface either. The consideration is about if you did start to add more formats, you would want to make sure that all temporal formats have a runtime.
I think you are confusing interfaces and inheritance, though. Things do not need to be anything alike to share an interface. The IDisposable interface provides by Microsoft is for any class that should be disposed of in a specific way. The classes that implement that have nothing to do with each other.
@@IAmTimCorey Exactly. You are agreeing with me. I think maybe you have changed how you think about this in the intervening years or you don't remember what you said in your video.
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"?
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();}
How did I miss this video? RU-vid 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: ru-vid.com/group/PLLWMQd6PeGY3ob0Ga6vn1czFZfW6e-FLr I also use these topics in my full projects (TimCo Retail Manager, for example).
What I have realized is that "interface" in SOLID doesn't really correspond to interfaces in C#. Though C# interfaces do facilitate interface segregation if used correctly. To me ISP is not just about syntax. It is easy to think that it is while looking at all the samples using "interfaces". There are languages that don't have "interfaces" but you can use other patterns to essentially achieve the same. To me, this is the difference between understanding the principle and just implementing a code pattern.
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 RU-vid version of TimCo can be found here also - ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-Xtt6mS0p2_c.html
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?
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, 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.
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?
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😃
