Design Patterns: Liskov Substitution Principle Explained Practically in C# (The L in SOLID)

แชร์
ฝัง
  • เผยแพร่เมื่อ 23 ธ.ค. 2024

ความคิดเห็น •

  • @ethanvenencia5653
    @ethanvenencia5653 3 ปีที่แล้ว +19

    3 years old but still quality content. Cheers man!

  • @RalfsBalodis
    @RalfsBalodis 4 ปีที่แล้ว +17

    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

    • @IAmTimCorey
      @IAmTimCorey  4 ปีที่แล้ว +2

      As always, Thank you!

  • @vero7427
    @vero7427 ปีที่แล้ว +5

    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 :)

  • @xcyron
    @xcyron 2 ปีที่แล้ว +3

    Learned so much in these 3 courses so far, this is seriously the best tutorial on SOLID that i came across.

  • @deltacap0192
    @deltacap0192 3 ปีที่แล้ว +3

    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...

    • @IAmTimCorey
      @IAmTimCorey  3 ปีที่แล้ว +2

      I am glad it was so helpful.

  • @mitchellbroue4778
    @mitchellbroue4778 4 ปีที่แล้ว +6

    Great video. This is the first presentation that has enough clear explanation to solidify the LSP principles. Full marks.

    • @IAmTimCorey
      @IAmTimCorey  4 ปีที่แล้ว

      Glad it was helpful!

  • @pranaygawand4884
    @pranaygawand4884 5 ปีที่แล้ว +10

    Awesome work again Tim! Never understood LSP event after spending hours on the internet reading blogs and articles. Thank you so much!

    • @IAmTimCorey
      @IAmTimCorey  5 ปีที่แล้ว

      I'm glad this was helpful to you.

  • @priyankapardesiramachander871
    @priyankapardesiramachander871 4 ปีที่แล้ว +4

    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.

    • @IAmTimCorey
      @IAmTimCorey  4 ปีที่แล้ว +1

      You are most welcome. Thanks for watching.

  • @Redpill99
    @Redpill99 ปีที่แล้ว +4

    Thank you Tim for all the free content.

  • @hayleyha9433
    @hayleyha9433 4 ปีที่แล้ว +3

    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

    • @IAmTimCorey
      @IAmTimCorey  4 ปีที่แล้ว +1

      Glad it was helpful!

  • @sebainones
    @sebainones 3 ปีที่แล้ว +2

    One of the best explanations I've ever found on this pricniple that sometimes it could be tricky or confusing. Thanks a lot!

  • @iandalrymple7255
    @iandalrymple7255 3 ปีที่แล้ว +3

    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.

    • @IAmTimCorey
      @IAmTimCorey  3 ปีที่แล้ว +3

      I appreciate the kind words. I am glad you have found my content so valuable.

  • @mattak77
    @mattak77 4 ปีที่แล้ว +10

    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.

    • @IAmTimCorey
      @IAmTimCorey  4 ปีที่แล้ว

      Glad it was helpful!

  • @bobcat235
    @bobcat235 4 ปีที่แล้ว +8

    Tim Corey, you are a gift from God for explaining this stuff. Thankyou!

    • @IAmTimCorey
      @IAmTimCorey  4 ปีที่แล้ว +1

      You are welcome.

    • @fisheralaric692
      @fisheralaric692 3 ปีที่แล้ว

      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

    • @alonsobentley3351
      @alonsobentley3351 3 ปีที่แล้ว

      @Fisher Alaric instablaster =)

    • @fisheralaric692
      @fisheralaric692 3 ปีที่แล้ว

      @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.

    • @fisheralaric692
      @fisheralaric692 3 ปีที่แล้ว

      @Alonso Bentley it worked and I now got access to my account again. Im so happy!
      Thanks so much, you saved my account!

  • @bagratzakaryan8871
    @bagratzakaryan8871 ปีที่แล้ว +2

    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.

    • @IAmTimCorey
      @IAmTimCorey  ปีที่แล้ว +3

      Awesome! I’m glad it was helpful.

  • @LarryPeteet
    @LarryPeteet 4 ปีที่แล้ว +2

    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!!

  • @dejamirgianelli6231
    @dejamirgianelli6231 4 ปีที่แล้ว +2

    One of the best explanations I've seen at TH-cam.

  • @pradeepbetty
    @pradeepbetty 3 ปีที่แล้ว +1

    Thank goodness,.. At last, a more practical example than the rest of the internet,... Thank you TIM.

  • @timmyers9798
    @timmyers9798 6 ปีที่แล้ว +2

    LOL, "Whatever you do, don't freak out" ... loved that comment. Great video. Thanks man.

    • @IAmTimCorey
      @IAmTimCorey  6 ปีที่แล้ว

      I'm glad you enjoyed it.

  • @jesphaylobo8105
    @jesphaylobo8105 3 ปีที่แล้ว +2

    That was a super example and a great explanation about interfaces. I now feel comfortable with interfaces.

  • @Dame4Lyf3
    @Dame4Lyf3 6 ปีที่แล้ว +1

    Great series and have been invaluable to becoming a better programmer, thanks for your time in explaining these concepts to a fledging developer.

    • @IAmTimCorey
      @IAmTimCorey  6 ปีที่แล้ว

      I'm happy that it has helped you develop as a programmer. That's why I make these videos.

  • @Reaper7mk
    @Reaper7mk 3 ปีที่แล้ว +1

    What a practical and beautifully sophisticated example. Bravo sir.

  • @maricelpurusniuc7038
    @maricelpurusniuc7038 3 ปีที่แล้ว +1

    Great series, with just the right amount of technical details and explanations

  • @gerardhayden6568
    @gerardhayden6568 ปีที่แล้ว +3

    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!

  • @kmorgan26
    @kmorgan26 5 ปีที่แล้ว +2

    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.

    • @IAmTimCorey
      @IAmTimCorey  5 ปีที่แล้ว

      Awesome! I'm glad it was so helpful.

  • @solr4cc
    @solr4cc ปีที่แล้ว +2

    Finally very good explanation of LSP. Great content!

    • @IAmTimCorey
      @IAmTimCorey  ปีที่แล้ว +2

      Thank you!

    • @Paul-uo9sv
      @Paul-uo9sv ปีที่แล้ว

      @@IAmTimCorey Your vids are awesome. thanks

  • @n9434178
    @n9434178 6 ปีที่แล้ว +1

    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!

  • @thomascaedere
    @thomascaedere 6 ปีที่แล้ว +2

    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!

    • @IAmTimCorey
      @IAmTimCorey  6 ปีที่แล้ว

      I'd have to go back and watch, but this sounds like a reasonable suggestion. Thanks!

  • @RaterisimoCBA
    @RaterisimoCBA 3 ปีที่แล้ว +1

    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 !

  • @alex44483
    @alex44483 6 ปีที่แล้ว +1

    Really enjoying this series, thanks for making it :) You explain things a lot clearer than others

    • @IAmTimCorey
      @IAmTimCorey  6 ปีที่แล้ว

      I'm glad you are enjoying it.

  • @Neo8019
    @Neo8019 4 ปีที่แล้ว +2

    Great tutorial, thanks! You create one of the best ones out there. Keep up the great work.

  • @shacham85
    @shacham85 6 ปีที่แล้ว

    Thank you for this. This is by far the best explanation of Liskovs principle I have seen yet.

    • @IAmTimCorey
      @IAmTimCorey  6 ปีที่แล้ว

      I am glad you found it valuable.

  • @callumhaynes1384
    @callumhaynes1384 4 ปีที่แล้ว

    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 :)

  • @SuperBbbbssss
    @SuperBbbbssss 6 ปีที่แล้ว +1

    I have all the 5 SOLID principles - thanks for your effort brother.

  • @stephenyork7318
    @stephenyork7318 4 ปีที่แล้ว +1

    Around 9:00, something I've never considered! Love your work, thanks heaps.

  • @TheAngelOfDeath01
    @TheAngelOfDeath01 6 ปีที่แล้ว +1

    "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

    • @IAmTimCorey
      @IAmTimCorey  6 ปีที่แล้ว +1

      Multi-inheritance can be ... challenging. Glad you enjoyed the video.

    • @TheAngelOfDeath01
      @TheAngelOfDeath01 6 ปีที่แล้ว

      IAmTimCorey meaning you write C++ or JAVA yourself??

    • @IAmTimCorey
      @IAmTimCorey  6 ปีที่แล้ว +1

      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.

    • @TheAngelOfDeath01
      @TheAngelOfDeath01 6 ปีที่แล้ว

      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.

    • @IAmTimCorey
      @IAmTimCorey  6 ปีที่แล้ว +1

      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.

  • @niyaziozturk3967
    @niyaziozturk3967 4 ปีที่แล้ว

    Thank you Tim. I studied this four five years ago and totally forgotton. Very good tutorial, thank you!

    • @IAmTimCorey
      @IAmTimCorey  4 ปีที่แล้ว

      You're very welcome!

  • @NeoPlanetx
    @NeoPlanetx 6 ปีที่แล้ว +1

    Great material Tim, keep up to good work! Thank's for helping the community with your knowledgment!

    • @IAmTimCorey
      @IAmTimCorey  6 ปีที่แล้ว

      I appreciate the kind words.

  • @paulofernandoee
    @paulofernandoee 2 ปีที่แล้ว +3

    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.

    • @IAmTimCorey
      @IAmTimCorey  2 ปีที่แล้ว +2

      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/

  • @harag9
    @harag9 ปีที่แล้ว +2

    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.

  • @amnesia3490
    @amnesia3490 4 ปีที่แล้ว +1

    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.

    • @IAmTimCorey
      @IAmTimCorey  4 ปีที่แล้ว +1

      Thank you, that is the goal.

  • @aimanalnami7655
    @aimanalnami7655 2 ปีที่แล้ว +7

    Thanks tim this is real world scenario ... better then shape and rectangle 😂

  • @pw.70
    @pw.70 5 ปีที่แล้ว

    I found this more intuitive than the Open/Closed Principle. Excellent tutorial - thank you.

  • @wilsonnunes7338
    @wilsonnunes7338 2 ปีที่แล้ว +2

    Valeu!

  • @RobertMunteanu105
    @RobertMunteanu105 2 ปีที่แล้ว +2

    Hey Tim, thanks a lot for this video!
    I was having a quick look on things. I'm having an interview tomorrow 😄

  • @vartikagupta8816
    @vartikagupta8816 3 ปีที่แล้ว +4

    How do you find the easiest way to explain things. I think I have understood it for good this time. Thanks Tim!

  • @mimart3011
    @mimart3011 3 ปีที่แล้ว

    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

  • @nikolaykolev5431
    @nikolaykolev5431 6 ปีที่แล้ว +2

    Hey Tim, great content, please keep up the good work, looking forward :)

  • @sbeasley1120
    @sbeasley1120 5 ปีที่แล้ว

    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.

    • @IAmTimCorey
      @IAmTimCorey  5 ปีที่แล้ว

      Yep, that's a good convention.

  • @GuRuGeorge03
    @GuRuGeorge03 3 ปีที่แล้ว

    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

  • @xcyron
    @xcyron 2 ปีที่แล้ว

    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.

    • @IAmTimCorey
      @IAmTimCorey  2 ปีที่แล้ว

      I am glad it was so helpful.

  • @rasikagayangunarathna
    @rasikagayangunarathna 4 ปีที่แล้ว +2

    Thank you very much for this valuable tutorial.

  • @ruifeng4901
    @ruifeng4901 4 ปีที่แล้ว +2

    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!

    • @IAmTimCorey
      @IAmTimCorey  4 ปีที่แล้ว +3

      Thanks for the suggestion. I have added it to the list of possible future topics.

  • @catrielportela1885
    @catrielportela1885 11 หลายเดือนก่อน +1

    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

  • @allmhuran
    @allmhuran 6 ปีที่แล้ว +1

    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.

    • @IAmTimCorey
      @IAmTimCorey  6 ปีที่แล้ว +2

      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.

    • @allmhuran
      @allmhuran 6 ปีที่แล้ว +1

      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.

  • @sulabee9228
    @sulabee9228 3 ปีที่แล้ว +1

    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?

  • @harag9
    @harag9 6 ปีที่แล้ว +3

    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.

    • @IAmTimCorey
      @IAmTimCorey  6 ปีที่แล้ว +2

      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.

    • @peteredenburg6464
      @peteredenburg6464 6 ปีที่แล้ว

      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.

    • @peteredenburg6464
      @peteredenburg6464 6 ปีที่แล้ว +1

      Sorry, I found it. Now it works after changing in the proper places.

    • @darrenbrook4641
      @darrenbrook4641 5 ปีที่แล้ว

      @@peteredenburg6464 Do you have code with those changes please?

  • @georginakissinger3492
    @georginakissinger3492 3 ปีที่แล้ว

    Best explanation ever. Thank you Tim Corey.

  • @hugogogo13
    @hugogogo13 ปีที่แล้ว +2

    LSP could be summed up as ALP => "Avoid Lazy Polymorphism".
    Thank you for your videos Tim!

  • @LarryPeteet
    @LarryPeteet 4 ปีที่แล้ว +3

    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.

  • @AnotherFancyUser
    @AnotherFancyUser 3 ปีที่แล้ว +1

    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?.

    • @IAmTimCorey
      @IAmTimCorey  3 ปีที่แล้ว +1

      Pretty sure I explain it later on.

  • @shivaayJikiduniya
    @shivaayJikiduniya 4 ปีที่แล้ว +2

    Thanks tim, this helps me a lot.
    Awesome bro!!!

  • @torrvic1156
    @torrvic1156 ปีที่แล้ว

    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.

    • @IAmTimCorey
      @IAmTimCorey  ปีที่แล้ว +1

      I am glad it was helpful.

  • @longuinni
    @longuinni 6 ปีที่แล้ว +1

    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?

    • @IAmTimCorey
      @IAmTimCorey  6 ปีที่แล้ว +1

      Yes, good catch. That would have been something good to point out (and implement). I just forgot to do so.

    • @longuinni
      @longuinni 6 ปีที่แล้ว +2

      Great. I think I'm learning... slowly but learning. I'm look forward for the Interface segregation principle video

  • @Krajca916
    @Krajca916 5 ปีที่แล้ว +4

    Shouldn't "manager" field in IManaged be of type IManager? It's minor thing but it will say clearly that only manager can manage.

    • @IAmTimCorey
      @IAmTimCorey  5 ปีที่แล้ว

      Yep, that's a good point.

    • @simon-white
      @simon-white 5 ปีที่แล้ว

      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.

    • @angelmunoz6332
      @angelmunoz6332 4 ปีที่แล้ว

      Good point

  • @colin-campbell
    @colin-campbell 6 ปีที่แล้ว +3

    Tim Corey for president

    • @IAmTimCorey
      @IAmTimCorey  6 ปีที่แล้ว +1

      Ha! There's a job I don't want. I'm happy making developers' lives easier.

  • @jasonk.3595
    @jasonk.3595 6 ปีที่แล้ว

    Thank you Tim, your videos are excellent. This video in particular helped me a lot. Much appreciated. Cheers!

  • @zulhishamtan4308
    @zulhishamtan4308 4 ปีที่แล้ว +2

    This is really good.
    Thank you very much.

  • @lesmonkmorison2828
    @lesmonkmorison2828 3 ปีที่แล้ว +1

    another great video Tim, thanks much.

  • @Kavorka666
    @Kavorka666 ปีที่แล้ว +1

    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?

    • @johnikeson3114
      @johnikeson3114 ปีที่แล้ว +3

      You have an IManaged interface which needs to extend to the IEmployee interface. Interface can't extend a concrete class. IManaged : BaseEmployee [x]

  • @Oleg-ng7ss
    @Oleg-ng7ss 3 ปีที่แล้ว

    Thanks! Good explanation. Very helpful for me. Now I understand what is LSP.

  • @peternguyen9382
    @peternguyen9382 8 หลายเดือนก่อน +1

    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

    • @IAmTimCorey
      @IAmTimCorey  8 หลายเดือนก่อน +3

      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.

    • @peternguyen9382
      @peternguyen9382 8 หลายเดือนก่อน +1

      @@IAmTimCorey thanks! your channel helps me alot!

  • @SaharR-bh1ps
    @SaharR-bh1ps ปีที่แล้ว +1

    Thank you for this useful video. I have question, why do we need IEmployee despite BaseEmployee ?

    • @torrvic1156
      @torrvic1156 ปีที่แล้ว

      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.

  • @MrDanieldamianov
    @MrDanieldamianov 4 ปีที่แล้ว +2

    Helpful as always

  • @DoomCatcher
    @DoomCatcher 3 ปีที่แล้ว +1

    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?

    • @IAmTimCorey
      @IAmTimCorey  3 ปีที่แล้ว +4

      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.

  • @ashishdawale4790
    @ashishdawale4790 6 ปีที่แล้ว +1

    Very well explained. Thank you Tim!

    • @IAmTimCorey
      @IAmTimCorey  6 ปีที่แล้ว

      You are most welcome. Thanks for watching.

  • @paulonobrega942
    @paulonobrega942 2 ปีที่แล้ว +1

    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;
    }

    • @chrisvarns
      @chrisvarns 2 ปีที่แล้ว +4

      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.

  • @esteenbrink
    @esteenbrink 3 ปีที่แล้ว +1

    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.

    • @IAmTimCorey
      @IAmTimCorey  3 ปีที่แล้ว

      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.

    • @aidubxr2016
      @aidubxr2016 3 ปีที่แล้ว

      @@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?

  • @dennohnjogu4028
    @dennohnjogu4028 ปีที่แล้ว

    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?

    • @burgundyhome7492
      @burgundyhome7492 3 หลายเดือนก่อน

      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.

  • @khashayarpakkhesal6026
    @khashayarpakkhesal6026 ปีที่แล้ว

    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) ?

  • @nagamanikanta4251
    @nagamanikanta4251 3 ปีที่แล้ว

    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?.

  • @asmitapatil9393
    @asmitapatil9393 5 ปีที่แล้ว +3

    What's difference between polymorphism and liskov substitution principal?

    • @orcbloodtech422
      @orcbloodtech422 5 ปีที่แล้ว

      That's a good question.

    • @IAmTimCorey
      @IAmTimCorey  5 ปีที่แล้ว +7

      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.

    • @xlnt2new
      @xlnt2new 5 ปีที่แล้ว +3

      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?

    • @orcbloodtech422
      @orcbloodtech422 5 ปีที่แล้ว +1

      @@xlnt2new You both cleared it up great! And though I'm not OP, I'll still say thanks. So thanks!

    • @xlnt2new
      @xlnt2new 5 ปีที่แล้ว

      @@orcbloodtech422 Waaagh!

  • @vinuhosanagar1
    @vinuhosanagar1 6 ปีที่แล้ว

    Best explanation ever. Thank you

    • @IAmTimCorey
      @IAmTimCorey  6 ปีที่แล้ว +1

      I'm glad it came through clearly. It can be a tricky one.

  • @filip4092
    @filip4092 3 ปีที่แล้ว +2

    Perfect explanation thanks a lot.

    • @tomthelestaff-iamtimcorey7597
      @tomthelestaff-iamtimcorey7597 3 ปีที่แล้ว +1

      We are glad you found it helpful and appreciate your sharing your thoughts. Thanks for being a part of this great community.

  • @RoyWagemakers
    @RoyWagemakers ปีที่แล้ว +1

    Great video. Easy to follow

  • @CybeargPlays
    @CybeargPlays 6 ปีที่แล้ว +1

    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?

    • @IAmTimCorey
      @IAmTimCorey  6 ปีที่แล้ว

      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.

  • @olliegelton5976
    @olliegelton5976 2 ปีที่แล้ว +1

    very nice.. thank you Tim

  • @recepcakir4866
    @recepcakir4866 3 ปีที่แล้ว

    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.

  • @tsachigal1744
    @tsachigal1744 ปีที่แล้ว +1

    Best explanation. Thank you

  • @alinawaz4034
    @alinawaz4034 6 ปีที่แล้ว +1

    Your videos are Amazing Like Always Thanks! for sharing your knowledge with us May Allah Increase your knowledge! and our also.

  • @canpehlivan5090
    @canpehlivan5090 10 หลายเดือนก่อน

    Hey Tim! Thanks for the video, man!

    • @IAmTimCorey
      @IAmTimCorey  10 หลายเดือนก่อน

      You are welcome.

  • @amarnathsharma
    @amarnathsharma 8 หลายเดือนก่อน +1

    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.

    • @IAmTimCorey
      @IAmTimCorey  8 หลายเดือนก่อน

      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.

  • @vagalson
    @vagalson 4 ปีที่แล้ว

    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?

    • @IAmTimCorey
      @IAmTimCorey  4 ปีที่แล้ว +3

      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.

  • @CybeargPlays
    @CybeargPlays 6 ปีที่แล้ว +5

    Naming things is hard, but might I retroactively suggest Employee be renamed to ManagedEmployee and BaseEmployee be renamed to Employee?
    Great video!

    • @IAmTimCorey
      @IAmTimCorey  6 ปีที่แล้ว

      Thanks for the suggestion and you are correct, naming is hard.

  • @stephenyork7318
    @stephenyork7318 4 ปีที่แล้ว

    At 22:35, any reason for using `IEmployee Manager` instead of `IManager Manager` and the same on AssignManager?

    • @IAmTimCorey
      @IAmTimCorey  4 ปีที่แล้ว +4

      Using different interfaces, we get access to different properties and methods.

    • @felipe.raposo
      @felipe.raposo ปีที่แล้ว

      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?

  • @PS-vj6jz
    @PS-vj6jz 2 ปีที่แล้ว +2

    Perfect. Thanks.
    Hello from Russia (o.o)/

  • @brandongillett2616
    @brandongillett2616 6 ปีที่แล้ว +1

    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?

    • @IAmTimCorey
      @IAmTimCorey  6 ปีที่แล้ว

      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.

  • @araksabramovic6156
    @araksabramovic6156 ปีที่แล้ว +2

    This video gave me an offer) Thank you bro

  • @desmond80in
    @desmond80in 5 ปีที่แล้ว +1

    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..

    • @IAmTimCorey
      @IAmTimCorey  5 ปีที่แล้ว

      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.

  • @soucianceeqdamrashti8175
    @soucianceeqdamrashti8175 5 ปีที่แล้ว

    Really well explained with good examples!