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...
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 :)
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.
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.
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.
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.
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 !
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!
"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.
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.
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 :)
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.
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 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.
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.
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
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?
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.
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.
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!
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.
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.
When you first started I thought 'here we go again! messing with something in a weird way when it's easily fixed' but it made sense in the end. I like S and L but still see as many problems as solutions with OCP to be honest for the work I do. Before this I would have added a variable to all Employees saying IsManager and IsCEO and then had if statements within Employee to control usage of methods. Messier and worse if things were more complex.
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?.
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
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?
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?.
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.
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?
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.
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?
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?
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.
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.
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.
3 years old but still quality content. Cheers man!
Thanks!
This is timeless ❤
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.
Learned so much in these 3 courses so far, this is seriously the best tutorial on SOLID that i came across.
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!
Thank you Tim for all the free content.
Thank you!
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.
Great video. This is the first presentation that has enough clear explanation to solidify the LSP principles. Full marks.
Glad it was helpful!
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!
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!
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.
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 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!
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.
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!
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
Thank goodness,.. At last, a more practical example than the rest of the internet,... Thank you TIM.
You are welcome.
One of the best explanations I've seen at UA-cam.
Thank you!
LOL, "Whatever you do, don't freak out" ... loved that comment. Great video. Thanks man.
I'm glad you enjoyed it.
What a practical and beautifully sophisticated example. Bravo sir.
You are welcome.
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!
😆
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.
Around 9:00, something I've never considered! Love your work, thanks heaps.
Happy to help!
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.
Great series, with just the right amount of technical details and explanations
Thanks!
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!
Finally very good explanation of LSP. Great content!
Thank you!
@@IAmTimCorey Your vids are awesome. thanks
Thanks tim this is real world scenario ... better then shape and rectangle 😂
You are welcome.
I have all the 5 SOLID principles - thanks for your effort brother.
You are welcome.
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.
Valeu!
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.
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!
Great tutorial, thanks! You create one of the best ones out there. Keep up the great work.
Thank you!
Really enjoying this series, thanks for making it :) You explain things a lot clearer than others
I'm glad you are enjoying it.
"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!
I found this more intuitive than the Open/Closed Principle. Excellent tutorial - thank you.
You are welcome.
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.
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 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.
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!
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/
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.
Hey Tim, thanks a lot for this video!
I was having a quick look on things. I'm having an interview tomorrow 😄
Best wishes!
Thank you very much for this valuable tutorial.
You are welcome.
Hey Tim, great content, please keep up the good work, looking forward :)
Thanks and will do.
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.
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
Best explanation ever. Thank you Tim Corey.
Much appreciated, thanks for watching
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?
LSP could be summed up as ALP => "Avoid Lazy Polymorphism".
Thank you for your videos Tim!
You are welcome.
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.
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.
Thanks tim, this helps me a lot.
Awesome bro!!!
You are welcome.
Tim Corey for president
Ha! There's a job I don't want. I'm happy making developers' lives easier.
Thanks! Good explanation. Very helpful for me. Now I understand what is LSP.
Thanks for watching the video and for sharing your thoughts.
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.
Your videos are Amazing Like Always Thanks! for sharing your knowledge with us May Allah Increase your knowledge! and our also.
Thanks!
This is really good.
Thank you very much.
Glad you like it!
another great video Tim, thanks much.
You are welcome.
Thank you Tim, your videos are excellent. This video in particular helped me a lot. Much appreciated. Cheers!
Awesome!
Very well explained. Thank you Tim!
You are most welcome. Thanks for watching.
Best explanation ever. Thank you
I'm glad it came through clearly. It can be a tricky one.
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.
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?
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]
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.
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
Best explanation. Thank you
You are welcome.
Perfect. Thanks.
Hello from Russia (o.o)/
You are welcome.
When you first started I thought 'here we go again! messing with something in a weird way when it's easily fixed' but it made sense in the end.
I like S and L but still see as many problems as solutions with OCP to be honest for the work I do.
Before this I would have added a variable to all Employees saying IsManager and IsCEO and then had if statements within Employee to control usage of methods. Messier and worse if things were more complex.
There's always a tradeoff. That's the biggest trick to learn in software development - when to accept which tradeoffs.
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.
Great video. Easy to follow
Great to hear!
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
Hey Tim! Thanks for the video, man!
You are welcome.
Covariance and contravariance: I feel like I’m back in my Tensor Calculus or General Relativity class!
I did not enjoy courses like that.
Helpful as always
Thank you!
This video gave me an offer) Thank you bro
Awesome!
very nice.. thank you Tim
You are welcome.
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?
Great explanation. Thank you
Glad it was helpful!
Really well explained with good examples!
Thanks!
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?.
Thanks Tim. you made it so simple.
You are welcome.
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.
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
Great tutorial. love your channel
Thanks!
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.
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?
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!
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.
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!
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.
This is awesome, thanks Tim!
Thanks for watching
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.
Great explanation, cleared everthing
Glad it helped!