After going through multiple resources these are by far the best SOLID Principle explanations I've come across so far. I have a much better understanding now :)
Fortunately landed here for an interview purpose. Just 13 minutes into the video and now I will never be able to forget it. No more brush-ups before the interview. It will be a part of my daily routine now. I have always used preconditions, type checks, typecasting, or dummy implementations to escape such scenarios. Never knew that was a violation of this textbook rule. I had tried explanations with practical examples earlier too, but the simplicity of example and language in your video beats all of them. Thank you so much...
I am addicted to your teaching style. Reading these design concepts from books is one thing, but a code example really opens up one's mind for better understanding. Thank you for all the tutorials, and special thanks for making the source code available.
This is the best explanation on the internet for SOLID. Thank you for making separate videos with code demo for each topic, they are extremely helpful and after watching your seri on this topic, I don't feel vague a bout SOLID anymore
This might sound weird but I must say I regret not watching all of Tim Corey C# videos from the start of my programming journey. Would have saved me a lot of time. Thank you sir for the work you have done.
This is by far the best and cleanest explanation with hands on coding. Also some tips for Visual Studio shortcuts, brief explanation for abstract class helped me learn more than SOLID principle. Thank you so much.
I dont mean to be so off topic but does any of you know a trick to log back into an instagram account?? I was stupid lost my account password. I would appreciate any assistance you can offer me
@Alonso Bentley I really appreciate your reply. I got to the site thru google and I'm waiting for the hacking stuff atm. I see it takes quite some time so I will get back to you later with my results.
Frankly speaking, I read up to 10 articles about LSP and watched multiple videos, and I couldn't really understand the principle of LSP, but your video is perfect, even I do not know C# language, but I know Typescript thought it would be difficult to understand, but not, it's helped me thanks a lot for the explanation.
Thanks Mr Corey. You are a Rockstar. I have been with Microsoft Technology Stack for 25 Years (MSDOS, Microsoft C) and keep trying to learn some of the things you know so well!!
Tim, your Car/Deckchair analogy reminded me of an old Jeremy Clarkson clip, where he was detailing what makes a supercar, when he said something like "Of course, not everything painted bright red with the engine centrally mounted behind the driver is a supercar" and the camera pans back to revel him standing by a ride-on lawn mower!
Great stuff, Tim! I have read about inheritance several times before, and now that I've watched this video, I think I have a waaaay better understanding of how to implement it. You have a great way of explaining rather complex concepts! Good on you.
Thank you Tim ! Very clear and very useful explanation to me. It really is a very complete answer to the question that I posted in response to your OCP video. Looking forward to your next videos!
Hey Tim, I really like the use cases you used for illustrating these problems. I'm encouraging all of my team members to have a look at this series about SOLID to make sure they are doing the right thing. One thing though, I would use the IManager input type for AssignManager method in stead of IEmployee and make the Manager property in IManaged of type IManager. This way, you're making sure we can only input a manager when assigning the manager. When retrieving the manager from the employee, we are certain the manager can in fact generate a performance review, which would make this implementation more safe i.m.o. It doesn't break anything about the fact that this video is very well explained. Thank you!
Another excellent class. I'll be taking one of your courses soon, I can see myself learning this way. Thank you for having this content for everyone, it's so helpful !
Best explanation i have seen, thanks for jumping straight to the code. I have always struggled to understand this principle, but now i understand it. Cheers Tim :)
"Learning" this in C++ back in my ooolld science class was a freaking nightmare, especially because of the ability to perform inheritance from MULTIPLE classes, etc. Glad to see you decided to include those abstract classes. ;-) hehe. Thanks for uploading; as always a good and informative video! :D
Yep. I haven't in a couple years but I've been a consultant off and on for years. In that time I've developed applications in FoxPro, Access, VBA, VB6, C, C++, Java, JavaScript, PowerShell, ObjectiveC, Python, PHP, VB.NET, and Delphi to name a few. At one point I stopped counting at 20+ languages that I had built applications in. I try to focus on C#, SQL, and JavaScript these days as much as I can though.
Whistles. I stuck with VBscript, PHP, JavaScript and a tiny-tiny amount of C++ (just enough to understand the concepts) PHP I'm good at, especially combined with Zend-Framework and MySQL, and the pivotal HTML, JavaScript and CSS combinations.
The trick is to realize that all languages fall roughly into two buckets: functional and object oriented. Once you are comfortable with how one of the buckets work, the differences between languages in that bucket are just syntax. The logic stays the same. So basically, you can think in C# (the concepts) but write in C++ or Java by just figuring out how to do x in the other language. It isn't as efficient (you Google a LOT) but you pick it up pretty quick.
Great Series Tim! It's really nice to see the principles blending in and complementing each other. If someday you have the time to make a video about covariance and contravariance, i believe you will be able to explain it in an excellent way, i have tried reading the msdn docs and watching other videos on this matter, i just cant understand it.
It was awesome explanation of Interface, Inheritence and other all that related stuff. Its not only explanation of princple it is also perfect example of understanding inheritence.
11:40 I like you mentioned one of the ways how to overcome this. One is have interfaces instead or you can/should/have to write tests to cover the cases where the LSP can be broken
I like making anything that uses Base in the class name abstract. Because it shouldn’t ever be used on its own. I’m glad that you talked through it here.
It really clicked when you said that CEO is not an employee. It immediately gave me the idea that a manager should be any class that implements an IManager interface that can then be dependency injected into any class that has a manager. In other words, getting rid of inheritance is just great, lol
When i finished the second video (O in Solid) i was like, wait, how do i acces additional methods and properties that aren't part of the interface now? And here we are at the solution for that. Amazing tutorial series.
Thank you Tim! Your video is very thought-provoking! After watching this video. As to the example you mentioned in the end about both cars and desks have wheels doesn't mean they're related enough to have an inheritance structure. It reminds of me the difference between 'is-a' and 'has-a' reslationship. Is it possible that you make some videos to illustrate these two relationships using some examples? Thanks again!
Hello Tim, great video men! I have a quick question, What happens if i need in my code to distinguish between different employees type, for example, i want to do something if the employee is Staff and other thing if is Manager. How would i be able to distinguish them apart if not by a employeeType attribute? Tell me your opinion! Thxxxx
Good video. Coming from a relational background, the "correct" solution in my mind is different from the one proposed here. Essentially, I'd say this: The manger of an employee is *not* a property of the employee. It is a relationship between two entities. As such, the solution would be to create a new class to model that relationship. We would then keep the set of all of those relationships in an containing entity which we might call the OrganisationalChart. That's somewhat specific to this example, but that's because the example involves relationships between entities, and the same sort of model should apply to any similar situation - ie, don't model relationships between entities as attributes of those entities - which is something that comes up quite often.
This is how we model that relationship in C# though. When using a class instance as a property, we aren't putting that class into our class (so we aren't putting a Manager into an Employee), we are essentially putting a reference to the other object in our current object (so Employee has a reference to the Manager class, not a copy of it). The classes still exist on their own. In that way, we could actually go up the org chart from any employee all the way to the CEO. We look at the Employee's manager, and then look at that manager's manager, and so on up the chain. I didn't add it but typically I would also include a List that is the subordinates of any Manager. If we create another object that is the relationships (the organizational chart), we are storing information about the Employee outside of the Employee class. That means keeping that data connected to the Employee while outside of its control. That is dangerous. It provides a possible synchronization issue if one changes without the other. If you have the Employee link to an OrgChart object, there is not any really difference then between this solution and directly linking to the Manager except you have added a layer of complexity without gaining any perceivable benefit. That is why, because of how class instances work, it is best in C# to assign a class instance to the Manager property and put it into the Employee class. Besides, if you were to ask me who my manager is, I would not refer to you an OrgChart. I would just tell you. That is what our application is doing.
Yep, I know that's how it's often modelled, for example in the entity framework (which does give the parent a collection of the children as you described). What I'm saying is that I don't think the approach is logically supportable. If I make anything a member of a class, then I'm saying that the class is responsible for that member. But the employee represented by the employee class is not responsible for the relationship between itself and its manager, so the manager (or manager reference) shouldn't be a member of the employee class. The same argument applies to the collection of employees (or employee references) in the manager object. Creating the org chart doesn't store information about the employee outside of the employee class. All of the properties of employees are still stored in employee objects. What the OrgChart does is store information about the relationships which exist between those employee objects. As a "proof by contradiction" of this, consider a company that only has a single employee. This employee has no manager. In fact they can never have a manager given this condition. But the employee can still be fully defined - this is trivially true, because they are in fact an employee. So it is possible to fully define the employee despite the absence of a manager. But if the employee class has a manager reference, and if that reference is null, then the employee has not been fully defined. Ergo, the employee class should not have a member which is a reference to a manager. I realise that this is not the way in which models are typically created (eg, in C#), but I'm not appealing to tradition according to any particular language, I'm looking at it from a more fundamental perspective rooted in predicate logic.
There's something that i don't understand with this principle (sorry , i'm new to this thing) what benefit do we get by applying this principle ? also at 5:12 if we just delete that line and left the method empty or replace it with Console.Writeline("You can't assign manager to CEO"); do we achieve LSP?
Great video again Tim, thanks. Nice and clean and well explained! However, I think I spotted an error on the "IManaged" interface - the property "Manager" should be an IManager type not an IEmployee type. Because when a "Manager" is assigned to that property you still want to have access to the CreateReports method the Manager has. Hope this makes sense.
Hello Harag and Tim, I tried implementing the change suggested here, but it has some more trickle downs that, when all are changed as a consequence of this first adaptation, I end up with errors in the code that I am not quite yet capable of fixing myself. This is my lack of knowledge of of c# course, but is it possible to provide a new download of the completed project with this change implemented? Thanks in advance.
Suggestion: "Track Active Item in Solution Explorer" under Tools, Options. This would let us watching easily see which file you are in. For example you were talking about Employee and showing Code for Employee but Solution Explorer on the screen was highlighting CEO.cs file.
Ok, I'm at 13:52 when he explained that a CEO is not an Employee because it fails the "is a" as a CEO does not have a Manager. I could be going ahead on the video or be wrong entirely, but wouldn't it be better to take out the Manager property (has a ) in the Employee class and create an interface called IHaveManager and implement it on the classes that has a manager?.
Thank you so much for excellent explanation of a very complicated matter Tim! This is really helpful and useful in the real life applications. I though I will never understand it properly. But it seems like I am starting to figure it out after you video. In global it is all about keeping wise balance between inheritance and interfaces. All of the three types of employees should have everything common in their base class and differences should be shown via interfaces. That is how I understood it.
Great video Tim. I think it's the first time that I really understood the LSP. But I've a question, do you think that the access modifier in the base class could be protected over public?
Thanks for raising the question, didn't realise method signatures in an Interface could reference the very Interface they're created in, it seems they're self-aware. In this case, AssignManager's input type could also be replaced with IManager.
Thanks for your work! I have a question, Why we need to replace instance of parent class by instance of child class? in which case we need to do that? Is it because we want polymorphism to be happened without any problems. Thanks
That's a common use-case. For instance, your application might rely on EmailClient, but you end up writing a child class called GoogleEmailClient and another called OutlookEmailClient. You can then use either in the place of the original class without disrupting anything.
This is very useful but I'm confused as to why you made an abstract baseemployee class to inherit from that implements the Imemployee interface rather than just getting the other classes to implement Iemployee?
If the base class implements IEmployee then all of the child classes are guaranteed to as well. That means we can refer to any object that has a base class of BaseEmployee as IEmployee and it will work properly.
Hi Tim, thanks a lot for the video. I have a question: Instead of creating a new base class and all of the interfaces doesn't this code at CEO Class makes it LSP compliant? public override void AssignManager(Employee manager) { Manager = null; }
No because if you had a GetManager() method, it would return null for a CEO and a manager for everyone else, the CEO behaviour breaks from Employee behaviour by silently dropping any Employee that is passed to it.
Why do you choose to inherit IManaged from IEmployee. It doesn't seem to add anything and creates a diamond inheritance tree for Employee since it now has IEmployee as a base class through IManaged and BaseEmployee.
Interfaces are not inheritance. They aren't base classes. You can have an interface applied more than once without an issue. An interface is just a contract. It says what the class will have in it. That's it. In certain circumstances, it can be useful to have a contract applied more than once, like in this case.
@@IAmTimCorey Had the exact same question as Ernst and got confused. The same happens to IManager, which inherits from IEmployee. How is it usefull in this case?
what if you overloaded the AssignManager() inside the Employee base class to have a version similar to what the CEO had 5:10 line 18? would you be compliant?
Actually just remove the implementation of AssignManager inside CEO and just pass null argument (.AssignManager(null)) in an instance of CEO. That would have been compliant to LSP because the child (CEO) would have supported all the Parent's (Employee) attributes. But this exercise is just so to demonstrate LSP.
Greate video thank you so much but a question came to my mind you have managed to remove repeated code by declaring BaseEmployee and separate the responsibility of each class by declaring interfaces but how would you manage to remove repeated code in Manager and CEO (GeneratePerformenceReview) ?
Thanks for the videos. It was a good explanation with a real-world example. could you please make one video applying the solid principles in a simple project?.
LSP is essentially a clarification of polymorphism. There are things you CAN do in polymorphism that you shouldn't do. LSP identifies the best design for polymorphism.
let me, let me - so polymorphism is a oop concept (how the language works, what you can do to objects) while LSP is a SOLID principle - what is a good way of using the oop, how to solve recurring problems, "do this in this way because you don't need to re-discover the hot water" type-a-deal (: Basically SOLID says - do as we say or suffer as we did, while oop says - hey, you can do this to an object! Was i Feynman enough?
Although I really appreciate your example, and its straightforwardness is part of that, one easy real-life problem I could see would be the GeneratePerformanceReview method having a lot of code in it. In this current design, that code would need to be replicated among all IManager classes. Since C# does not support multiple inheritance, what would be your solution in such a situation where both the IEmployee and the IManager (and, just for fun, maybe also IManaged) came with a lot of code that would be nice to reuse. Composition? I could see all that extensive code for how to generate a performance review being pulled out into, for example, a PerformanceReviewGenerator class (which, for good Unit Testing, would necessitate an IPerformanceReviewGenerator interface) that Managers and CEOs require (or instantiate) as part of their construction, and GeneratePerformanceReview just becomes a wrapper for calling the PerformanceReviewGenerator class's GeneratePerformanceReview method. Is that the approach you'd recommend in practice?
Yep. The key, though, would be to identify if performance reviews would change significantly between employee types. If so then you would probably have a method in the employee type class that managed the review (calls a bunch of methods to set it all up). If not, you could just have the review class injected into the employee. A lot of different approaches here but you are correct that we don't want to create duplicate code.
Awesome, thanks a lot, Tim! Just a question to make my mind clear; what you have done here, is it related to 'composition over inheritance'? I see there is a similarity between them, an answer would be perfect for me to figure it out.
That's the wrong direction. The parent can be replaced by the child. The child might have more options, and therefore cannot always be replaced by the parent.
Hi Tim. Thank you very much for your very helpful videos. I was wondering why we need the IEmployee interface, as BaseEmployee is already abstract. Do we really need IEmployee?
Interfaces are not concrete. We can put any IEmployee object in them. An abstract class is concrete. If we were going to add unit testing, it would be easier to mock an IEmployee item rather than a BaseEmployee.
but using IEmployee allows you to define a not manager employee as a manager, no? Wouldn't it make me sense to use IManager instead? Or am I missing something?
If BaseEmployee just implements IEmployee and doesn't add any members of its own, is there any benefit to having the IEmployee interface when BaseEmployee is abstract? Couldn't we just remove the IEmployee interface and change all the references to BaseEmployee instead?
Mostly we don't need IEmployee. However, there are a couple reasons why we might. First, BaseEmployee isn't abstract so we might add more things to it. If those changes cause a deviation for any reason, we might want the interface still. Second, if we are using dependency injection, we probably want the interface to make things easier to configure, more flexible, and easier to unit test.
So when implementing state pattern we will have different actions in the interface and different states will have their implementations. Some states done have any actions to perform so at that time we throw not implemented exception. What is the best way to implement that. e.g. Telephone class has multiple states- Idle, Ringing, Answered, OutofOrder and multiple actions could occur like Ring, Dial, Connect, Disconnect, Mute, etc... Not when the state is in Idel then Ring action will change its state, but when its Idel Disconnect action would throw an not Implemented exception. So what is the best way to implement in this scenario... Need you expert KT on this..
That isn't really the same thing as what we are discussing here. You are throwing the exception because the action doesn't make sense. I wouldn't call it an NotImplementedException. It is more of an invalid action rather than not being coded yet.
3 years old but still quality content. Cheers man!
Thanks!
This is timeless ❤
0:00 - Intro
1:32 - Demo code overview
3:04 - Liskov Substitution Principle: LSP Explained...
6:15 - Side note: Covariance and Contravariance, Preconditions Postconditions
10:17 - ...LSP Explained
13:58 - Considering the Open and close principle
17:24 - Implementing LSP: Refactoring demo code
29:23 - Note on abstraction in base classes
33:02 - Flexibility with LSP and Concluding remarks
As always, Thank you!
After going through multiple resources these are by far the best SOLID Principle explanations I've come across so far. I have a much better understanding now :)
Great to hear!
Learned so much in these 3 courses so far, this is seriously the best tutorial on SOLID that i came across.
Thank you!
Fortunately landed here for an interview purpose.
Just 13 minutes into the video and now I will never be able to forget it.
No more brush-ups before the interview. It will be a part of my daily routine now.
I have always used preconditions, type checks, typecasting, or dummy implementations to escape such scenarios. Never knew that was a violation of this textbook rule.
I had tried explanations with practical examples earlier too, but the simplicity of example and language in your video beats all of them.
Thank you so much...
I am glad it was so helpful.
Great video. This is the first presentation that has enough clear explanation to solidify the LSP principles. Full marks.
Glad it was helpful!
Awesome work again Tim! Never understood LSP event after spending hours on the internet reading blogs and articles. Thank you so much!
I'm glad this was helpful to you.
I am addicted to your teaching style. Reading these design concepts from books is one thing, but a code example really opens up one's mind for better understanding.
Thank you for all the tutorials, and special thanks for making the source code available.
You are most welcome. Thanks for watching.
Thank you Tim for all the free content.
Thank you!
This is the best explanation on the internet for SOLID. Thank you for making separate videos with code demo for each topic, they are extremely helpful and after watching your seri on this topic, I don't feel vague a bout SOLID anymore
Glad it was helpful!
One of the best explanations I've ever found on this pricniple that sometimes it could be tricky or confusing. Thanks a lot!
You are welcome.
This might sound weird but I must say I regret not watching all of Tim Corey C# videos from the start of my programming journey. Would have saved me a lot of time. Thank you sir for the work you have done.
I appreciate the kind words. I am glad you have found my content so valuable.
This is by far the best and cleanest explanation with hands on coding. Also some tips for Visual Studio shortcuts, brief explanation for abstract class helped me learn more than SOLID principle. Thank you so much.
Glad it was helpful!
Tim Corey, you are a gift from God for explaining this stuff. Thankyou!
You are welcome.
I dont mean to be so off topic but does any of you know a trick to log back into an instagram account??
I was stupid lost my account password. I would appreciate any assistance you can offer me
@Fisher Alaric instablaster =)
@Alonso Bentley I really appreciate your reply. I got to the site thru google and I'm waiting for the hacking stuff atm.
I see it takes quite some time so I will get back to you later with my results.
@Alonso Bentley it worked and I now got access to my account again. Im so happy!
Thanks so much, you saved my account!
Frankly speaking, I read up to 10 articles about LSP and watched multiple videos, and I couldn't really understand the principle of LSP, but your video is perfect, even I do not know C# language, but I know Typescript thought it would be difficult to understand, but not, it's helped me thanks a lot for the explanation.
Awesome! I’m glad it was helpful.
Thanks Mr Corey. You are a Rockstar. I have been with Microsoft Technology Stack for 25 Years (MSDOS, Microsoft C) and keep trying to learn some of the things you know so well!!
Wow, thanks
One of the best explanations I've seen at TH-cam.
Thank you!
Thank goodness,.. At last, a more practical example than the rest of the internet,... Thank you TIM.
You are welcome.
LOL, "Whatever you do, don't freak out" ... loved that comment. Great video. Thanks man.
I'm glad you enjoyed it.
That was a super example and a great explanation about interfaces. I now feel comfortable with interfaces.
Thanks for watching and sharing!
Great series and have been invaluable to becoming a better programmer, thanks for your time in explaining these concepts to a fledging developer.
I'm happy that it has helped you develop as a programmer. That's why I make these videos.
What a practical and beautifully sophisticated example. Bravo sir.
You are welcome.
Great series, with just the right amount of technical details and explanations
Thanks!
Tim, your Car/Deckchair analogy reminded me of an old Jeremy Clarkson clip, where he was detailing what makes a supercar, when he said something like "Of course, not everything painted bright red with the engine centrally mounted behind the driver is a supercar" and the camera pans back to revel him standing by a ride-on lawn mower!
😆
Great stuff, Tim! I have read about inheritance several times before, and now that I've watched this video, I think I have a waaaay better understanding of how to implement it. You have a great way of explaining rather complex concepts! Good on you.
Awesome! I'm glad it was so helpful.
Finally very good explanation of LSP. Great content!
Thank you!
@@IAmTimCorey Your vids are awesome. thanks
Thank you Tim ! Very clear and very useful explanation to me. It really is a very complete answer to the question that I posted in response to your OCP video. Looking forward to your next videos!
Great!
Hey Tim, I really like the use cases you used for illustrating these problems. I'm encouraging all of my team members to have a look at this series about SOLID to make sure they are doing the right thing.
One thing though, I would use the IManager input type for AssignManager method in stead of IEmployee and make the Manager property in IManaged of type IManager.
This way, you're making sure we can only input a manager when assigning the manager.
When retrieving the manager from the employee, we are certain the manager can in fact generate a performance review, which would make this implementation more safe i.m.o.
It doesn't break anything about the fact that this video is very well explained. Thank you!
I'd have to go back and watch, but this sounds like a reasonable suggestion. Thanks!
Another excellent class. I'll be taking one of your courses soon, I can see myself learning this way. Thank you for having this content for everyone, it's so helpful !
You are welcome.
Really enjoying this series, thanks for making it :) You explain things a lot clearer than others
I'm glad you are enjoying it.
Great tutorial, thanks! You create one of the best ones out there. Keep up the great work.
Thank you!
Thank you for this. This is by far the best explanation of Liskovs principle I have seen yet.
I am glad you found it valuable.
Best explanation i have seen, thanks for jumping straight to the code. I have always struggled to understand this principle, but now i understand it. Cheers Tim :)
Glad it helped!
I have all the 5 SOLID principles - thanks for your effort brother.
You are welcome.
Around 9:00, something I've never considered! Love your work, thanks heaps.
Happy to help!
"Learning" this in C++ back in my ooolld science class was a freaking nightmare, especially because of the ability to perform inheritance from MULTIPLE classes, etc. Glad to see you decided to include those abstract classes. ;-) hehe. Thanks for uploading; as always a good and informative video! :D
Multi-inheritance can be ... challenging. Glad you enjoyed the video.
IAmTimCorey meaning you write C++ or JAVA yourself??
Yep. I haven't in a couple years but I've been a consultant off and on for years. In that time I've developed applications in FoxPro, Access, VBA, VB6, C, C++, Java, JavaScript, PowerShell, ObjectiveC, Python, PHP, VB.NET, and Delphi to name a few. At one point I stopped counting at 20+ languages that I had built applications in. I try to focus on C#, SQL, and JavaScript these days as much as I can though.
Whistles. I stuck with VBscript, PHP, JavaScript and a tiny-tiny amount of C++ (just enough to understand the concepts) PHP I'm good at, especially combined with Zend-Framework and MySQL, and the pivotal HTML, JavaScript and CSS combinations.
The trick is to realize that all languages fall roughly into two buckets: functional and object oriented. Once you are comfortable with how one of the buckets work, the differences between languages in that bucket are just syntax. The logic stays the same. So basically, you can think in C# (the concepts) but write in C++ or Java by just figuring out how to do x in the other language. It isn't as efficient (you Google a LOT) but you pick it up pretty quick.
Thank you Tim. I studied this four five years ago and totally forgotton. Very good tutorial, thank you!
You're very welcome!
Great material Tim, keep up to good work! Thank's for helping the community with your knowledgment!
I appreciate the kind words.
Great Series Tim! It's really nice to see the principles blending in and complementing each other.
If someday you have the time to make a video about covariance and contravariance, i believe you will be able to explain it in an excellent way, i have tried reading the msdn docs and watching other videos on this matter, i just cant understand it.
Thanks for the suggestion. Please add it to the list on the suggestion site so others can vote on it as well: suggestions.iamtimcorey.com/
Great explanation and very clear, many thanks Tim. Not sure why I've not seen this video when I've seen your other SOLID videos. hmm.
Glad it was helpful!
It was awesome explanation of Interface, Inheritence and other all that related stuff. Its not only explanation of princple it is also perfect example of understanding inheritence.
Thank you, that is the goal.
Thanks tim this is real world scenario ... better then shape and rectangle 😂
You are welcome.
I found this more intuitive than the Open/Closed Principle. Excellent tutorial - thank you.
You are welcome.
Valeu!
Thank you!
Hey Tim, thanks a lot for this video!
I was having a quick look on things. I'm having an interview tomorrow 😄
Best wishes!
How do you find the easiest way to explain things. I think I have understood it for good this time. Thanks Tim!
Great! Thank is the goal. It takes me a few times myself.
11:40 I like you mentioned one of the ways how to overcome this. One is have interfaces instead or you can/should/have to write tests to cover the cases where the LSP can be broken
Hey Tim, great content, please keep up the good work, looking forward :)
Thanks and will do.
I like making anything that uses Base in the class name abstract. Because it shouldn’t ever be used on its own. I’m glad that you talked through it here.
Yep, that's a good convention.
It really clicked when you said that CEO is not an employee. It immediately gave me the idea that a manager should be any class that implements an IManager interface that can then be dependency injected into any class that has a manager. In other words, getting rid of inheritance is just great, lol
Great, super glad it helped
When i finished the second video (O in Solid) i was like, wait, how do i acces additional methods and properties that aren't part of the interface now? And here we are at the solution for that.
Amazing tutorial series.
I am glad it was so helpful.
Thank you very much for this valuable tutorial.
You are welcome.
Thank you Tim! Your video is very thought-provoking! After watching this video. As to the example you mentioned in the end about both cars and desks have wheels doesn't mean they're related enough to have an inheritance structure. It reminds of me the difference between 'is-a' and 'has-a' reslationship. Is it possible that you make some videos to illustrate these two relationships using some examples? Thanks again!
Thanks for the suggestion. I have added it to the list of possible future topics.
Hello Tim, great video men!
I have a quick question,
What happens if i need in my code to distinguish between different employees type, for example, i want to do something if the employee is Staff and other thing if is Manager. How would i be able to distinguish them apart if not by a employeeType attribute?
Tell me your opinion!
Thxxxx
Good video. Coming from a relational background, the "correct" solution in my mind is different from the one proposed here.
Essentially, I'd say this: The manger of an employee is *not* a property of the employee. It is a relationship between two entities. As such, the solution would be to create a new class to model that relationship. We would then keep the set of all of those relationships in an containing entity which we might call the OrganisationalChart.
That's somewhat specific to this example, but that's because the example involves relationships between entities, and the same sort of model should apply to any similar situation - ie, don't model relationships between entities as attributes of those entities - which is something that comes up quite often.
This is how we model that relationship in C# though. When using a class instance as a property, we aren't putting that class into our class (so we aren't putting a Manager into an Employee), we are essentially putting a reference to the other object in our current object (so Employee has a reference to the Manager class, not a copy of it). The classes still exist on their own. In that way, we could actually go up the org chart from any employee all the way to the CEO. We look at the Employee's manager, and then look at that manager's manager, and so on up the chain. I didn't add it but typically I would also include a List that is the subordinates of any Manager.
If we create another object that is the relationships (the organizational chart), we are storing information about the Employee outside of the Employee class. That means keeping that data connected to the Employee while outside of its control. That is dangerous. It provides a possible synchronization issue if one changes without the other. If you have the Employee link to an OrgChart object, there is not any really difference then between this solution and directly linking to the Manager except you have added a layer of complexity without gaining any perceivable benefit.
That is why, because of how class instances work, it is best in C# to assign a class instance to the Manager property and put it into the Employee class. Besides, if you were to ask me who my manager is, I would not refer to you an OrgChart. I would just tell you. That is what our application is doing.
Yep, I know that's how it's often modelled, for example in the entity framework (which does give the parent a collection of the children as you described). What I'm saying is that I don't think the approach is logically supportable.
If I make anything a member of a class, then I'm saying that the class is responsible for that member. But the employee represented by the employee class is not responsible for the relationship between itself and its manager, so the manager (or manager reference) shouldn't be a member of the employee class. The same argument applies to the collection of employees (or employee references) in the manager object.
Creating the org chart doesn't store information about the employee outside of the employee class. All of the properties of employees are still stored in employee objects. What the OrgChart does is store information about the relationships which exist between those employee objects.
As a "proof by contradiction" of this, consider a company that only has a single employee. This employee has no manager. In fact they can never have a manager given this condition. But the employee can still be fully defined - this is trivially true, because they are in fact an employee. So it is possible to fully define the employee despite the absence of a manager. But if the employee class has a manager reference, and if that reference is null, then the employee has not been fully defined. Ergo, the employee class should not have a member which is a reference to a manager.
I realise that this is not the way in which models are typically created (eg, in C#), but I'm not appealing to tradition according to any particular language, I'm looking at it from a more fundamental perspective rooted in predicate logic.
There's something that i don't understand with this principle (sorry , i'm new to this thing)
what benefit do we get by applying this principle ?
also at 5:12 if we just delete that line and left the method empty or replace it with Console.Writeline("You can't assign manager to CEO");
do we achieve LSP?
Great video again Tim, thanks. Nice and clean and well explained!
However, I think I spotted an error on the "IManaged" interface - the property "Manager" should be an IManager type not an IEmployee type. Because when a "Manager" is assigned to that property you still want to have access to the CreateReports method the Manager has. Hope this makes sense.
Yep, I didn't catch that. It would give the variable more access to the manager's methods and properties more easily. I would definitely change that.
Hello Harag and Tim,
I tried implementing the change suggested here, but it has some more trickle downs that, when all are changed as a consequence of this first adaptation, I end up with errors in the code that I am not quite yet capable of fixing myself. This is my lack of knowledge of of c# course, but is it possible to provide a new download of the completed project with this change implemented? Thanks in advance.
Sorry, I found it. Now it works after changing in the proper places.
@@peteredenburg6464 Do you have code with those changes please?
Best explanation ever. Thank you Tim Corey.
Much appreciated, thanks for watching
LSP could be summed up as ALP => "Avoid Lazy Polymorphism".
Thank you for your videos Tim!
You are welcome.
Suggestion: "Track Active Item in Solution Explorer" under Tools, Options.
This would let us watching easily see which file you are in. For example you were talking about Employee and showing Code for Employee but Solution Explorer on the screen was highlighting CEO.cs file.
Noted, thanks.
Ok, I'm at 13:52 when he explained that a CEO is not an Employee because it fails the "is a" as a CEO does not have a Manager.
I could be going ahead on the video or be wrong entirely, but wouldn't it be better to take out the Manager property (has a ) in the Employee class and create an interface called IHaveManager and implement it on the classes that has a manager?.
Pretty sure I explain it later on.
Thanks tim, this helps me a lot.
Awesome bro!!!
You are welcome.
Thank you so much for excellent explanation of a very complicated matter Tim! This is really helpful and useful in the real life applications. I though I will never understand it properly. But it seems like I am starting to figure it out after you video. In global it is all about keeping wise balance between inheritance and interfaces. All of the three types of employees should have everything common in their base class and differences should be shown via interfaces. That is how I understood it.
I am glad it was helpful.
Great video Tim. I think it's the first time that I really understood the LSP. But I've a question, do you think that the access modifier in the base class could be protected over public?
Yes, good catch. That would have been something good to point out (and implement). I just forgot to do so.
Great. I think I'm learning... slowly but learning. I'm look forward for the Interface segregation principle video
Shouldn't "manager" field in IManaged be of type IManager? It's minor thing but it will say clearly that only manager can manage.
Yep, that's a good point.
Thanks for raising the question, didn't realise method signatures in an Interface could reference the very Interface they're created in, it seems they're self-aware. In this case, AssignManager's input type could also be replaced with IManager.
Good point
Tim Corey for president
Ha! There's a job I don't want. I'm happy making developers' lives easier.
Thank you Tim, your videos are excellent. This video in particular helped me a lot. Much appreciated. Cheers!
Awesome!
This is really good.
Thank you very much.
Glad you like it!
another great video Tim, thanks much.
You are welcome.
Quick Question , if its not too much trouble. Why do we need to add IEmployee interface? Can't we just use BaseEmployee class to inherit from others?
You have an IManaged interface which needs to extend to the IEmployee interface. Interface can't extend a concrete class. IManaged : BaseEmployee [x]
Thanks! Good explanation. Very helpful for me. Now I understand what is LSP.
Thanks for watching the video and for sharing your thoughts.
Thanks for your work! I have a question, Why we need to replace instance of parent class by instance of child class? in which case we need to do that? Is it because we want polymorphism to be happened without any problems. Thanks
That's a common use-case. For instance, your application might rely on EmailClient, but you end up writing a child class called GoogleEmailClient and another called OutlookEmailClient. You can then use either in the place of the original class without disrupting anything.
@@IAmTimCorey thanks! your channel helps me alot!
Thank you for this useful video. I have question, why do we need IEmployee despite BaseEmployee ?
Maybe I am wrong but probably it is for a CEO who is not an employee but share something with Employee. Please tell me if I am wrong.
Helpful as always
Thank you!
This is very useful but I'm confused as to why you made an abstract baseemployee class to inherit from that implements the Imemployee interface rather than just getting the other classes to implement Iemployee?
If the base class implements IEmployee then all of the child classes are guaranteed to as well. That means we can refer to any object that has a base class of BaseEmployee as IEmployee and it will work properly.
Very well explained. Thank you Tim!
You are most welcome. Thanks for watching.
Hi Tim, thanks a lot for the video. I have a question:
Instead of creating a new base class and all of the interfaces doesn't this code at CEO Class makes it LSP compliant?
public override void AssignManager(Employee manager)
{
Manager = null;
}
No because if you had a GetManager() method, it would return null for a CEO and a manager for everyone else, the CEO behaviour breaks from Employee behaviour by silently dropping any Employee that is passed to it.
Why do you choose to inherit IManaged from IEmployee. It doesn't seem to add anything and creates a diamond inheritance tree for Employee since it now has IEmployee as a base class through IManaged and BaseEmployee.
Interfaces are not inheritance. They aren't base classes. You can have an interface applied more than once without an issue. An interface is just a contract. It says what the class will have in it. That's it. In certain circumstances, it can be useful to have a contract applied more than once, like in this case.
@@IAmTimCorey Had the exact same question as Ernst and got confused. The same happens to IManager, which inherits from IEmployee. How is it usefull in this case?
what if you overloaded the AssignManager() inside the Employee base class to have a version similar to what the CEO had 5:10 line 18? would you be compliant?
Actually just remove the implementation of AssignManager inside CEO and just pass null argument (.AssignManager(null)) in an instance of CEO. That would have been compliant to LSP because the child (CEO) would have supported all the Parent's (Employee) attributes.
But this exercise is just so to demonstrate LSP.
Greate video thank you so much but a question came to my mind you have managed to remove repeated code by declaring BaseEmployee and separate the responsibility of each class by declaring interfaces but how would you manage to remove repeated code in Manager and CEO (GeneratePerformenceReview) ?
Thanks for the videos. It was a good explanation with a real-world example. could you please make one video applying the solid principles in a simple project?.
What's difference between polymorphism and liskov substitution principal?
That's a good question.
LSP is essentially a clarification of polymorphism. There are things you CAN do in polymorphism that you shouldn't do. LSP identifies the best design for polymorphism.
let me, let me - so polymorphism is a oop concept (how the language works, what you can do to objects) while LSP is a SOLID principle - what is a good way of using the oop, how to solve recurring problems, "do this in this way because you don't need to re-discover the hot water" type-a-deal (:
Basically SOLID says - do as we say or suffer as we did, while oop says - hey, you can do this to an object!
Was i Feynman enough?
@@xlnt2new You both cleared it up great! And though I'm not OP, I'll still say thanks. So thanks!
@@orcbloodtech422 Waaagh!
Best explanation ever. Thank you
I'm glad it came through clearly. It can be a tricky one.
Perfect explanation thanks a lot.
We are glad you found it helpful and appreciate your sharing your thoughts. Thanks for being a part of this great community.
Great video. Easy to follow
Great to hear!
Although I really appreciate your example, and its straightforwardness is part of that, one easy real-life problem I could see would be the GeneratePerformanceReview method having a lot of code in it. In this current design, that code would need to be replicated among all IManager classes. Since C# does not support multiple inheritance, what would be your solution in such a situation where both the IEmployee and the IManager (and, just for fun, maybe also IManaged) came with a lot of code that would be nice to reuse.
Composition? I could see all that extensive code for how to generate a performance review being pulled out into, for example, a PerformanceReviewGenerator class (which, for good Unit Testing, would necessitate an IPerformanceReviewGenerator interface) that Managers and CEOs require (or instantiate) as part of their construction, and GeneratePerformanceReview just becomes a wrapper for calling the PerformanceReviewGenerator class's GeneratePerformanceReview method. Is that the approach you'd recommend in practice?
Yep. The key, though, would be to identify if performance reviews would change significantly between employee types. If so then you would probably have a method in the employee type class that managed the review (calls a bunch of methods to set it all up). If not, you could just have the review class injected into the employee. A lot of different approaches here but you are correct that we don't want to create duplicate code.
very nice.. thank you Tim
You are welcome.
Awesome, thanks a lot, Tim!
Just a question to make my mind clear; what you have done here, is it related to 'composition over inheritance'? I see there is a similarity between them, an answer would be perfect for me to figure it out.
Best explanation. Thank you
You are welcome.
Your videos are Amazing Like Always Thanks! for sharing your knowledge with us May Allah Increase your knowledge! and our also.
Thanks!
Hey Tim! Thanks for the video, man!
You are welcome.
In LSP, If T extends S and you just replace T with S and nothing else, no method behaviour should change but you said its ok.
That's the wrong direction. The parent can be replaced by the child. The child might have more options, and therefore cannot always be replaced by the parent.
Hi Tim. Thank you very much for your very helpful videos.
I was wondering why we need the IEmployee interface, as BaseEmployee is already abstract. Do we really need IEmployee?
Interfaces are not concrete. We can put any IEmployee object in them. An abstract class is concrete. If we were going to add unit testing, it would be easier to mock an IEmployee item rather than a BaseEmployee.
Naming things is hard, but might I retroactively suggest Employee be renamed to ManagedEmployee and BaseEmployee be renamed to Employee?
Great video!
Thanks for the suggestion and you are correct, naming is hard.
At 22:35, any reason for using `IEmployee Manager` instead of `IManager Manager` and the same on AssignManager?
Using different interfaces, we get access to different properties and methods.
but using IEmployee allows you to define a not manager employee as a manager, no?
Wouldn't it make me sense to use IManager instead? Or am I missing something?
Perfect. Thanks.
Hello from Russia (o.o)/
You are welcome.
If BaseEmployee just implements IEmployee and doesn't add any members of its own, is there any benefit to having the IEmployee interface when BaseEmployee is abstract? Couldn't we just remove the IEmployee interface and change all the references to BaseEmployee instead?
Mostly we don't need IEmployee. However, there are a couple reasons why we might. First, BaseEmployee isn't abstract so we might add more things to it. If those changes cause a deviation for any reason, we might want the interface still. Second, if we are using dependency injection, we probably want the interface to make things easier to configure, more flexible, and easier to unit test.
This video gave me an offer) Thank you bro
Awesome!
So when implementing state pattern we will have different actions in the interface and different states will have their implementations. Some states done have any actions to perform so at that time we throw not implemented exception. What is the best way to implement that.
e.g. Telephone class has multiple states- Idle, Ringing, Answered, OutofOrder and multiple actions could occur like Ring, Dial, Connect, Disconnect, Mute, etc...
Not when the state is in Idel then Ring action will change its state, but when its Idel Disconnect action would throw an not Implemented exception. So what is the best way to implement in this scenario...
Need you expert KT on this..
That isn't really the same thing as what we are discussing here. You are throwing the exception because the action doesn't make sense. I wouldn't call it an NotImplementedException. It is more of an invalid action rather than not being coded yet.
Really well explained with good examples!
Thanks!