SOLID Principles: Do You Really Understand Them?
Vložit
- čas přidán 20. 05. 2024
- People mention SOLID everywhere but very few do a good job of explaining it. I am hoping to put an end to that in this video so you can once and for all understand all the SOLID principles.
Learn the SOLID principles in depth in my new course: dometrain.com/course/from-zer...
☕️ I don’t accept paid sponsorships and I have turned off mid-video ads. You’re welcome! If you would like to support my channel see: ko-fi.com/alexhyett
📨 Join my free weekly newsletter for advice, technology and more: newsletter.alexhyett.com
🗺️ Backend Developer Roadmap: www.alexhyett.com/backend-dev...
📝 Read me instead: www.alexhyett.com/solid-princ...
🎓 RECOMMENDED COURSES (Use code FRIENDS10 for 10% off)
The Complete Web Developer Course - academy.zerotomastery.io/a/af...
The Complete Junior to Senior Web Developer Roadmap - academy.zerotomastery.io/a/af...
C#/.NET Bootcamp: The Fundamentals: academy.zerotomastery.io/a/af...
Complete SQL + Databases Bootcamp - academy.zerotomastery.io/a/af...
📚 RECOMMENDED BOOKS
Clean Code - geni.us/5AEwj2
Design Patterns - geni.us/5ncUt
Developer Hegemony - geni.us/lAXy
Pragmatic Programmer - geni.us/GfNj9
Data Structures and Algorithms Made Easy - geni.us/sqg6kJ
Refactoring - geni.us/ufAP0mE
Pragmatic Thinking and Learning - geni.us/x81A
⏳ TIMESTAMPS
00:00 - Introduction
00:30 - Single Responsibility Principle
01:51 - Open-Closed Principle
02:33 - Decorator Pattern
03:02 - Extension Methods
03:39 - Liskov Substitution Principle
04:18 - Interface Segregation Principle
05:11 - Dependency Inversion Principle
06:37 - Conclusion
🧑🏻💻 You can check out more of my favourite tools on my website: www.alexhyett.com/tech/
🔗 MY KEY LINKS
🌍 Blog - www.alexhyett.com/
🐘 Mastodon - social.alexhyett.com/@alex
🧑💻 WHO AM I
I’m Alex, a Software Developer and CZcams working in the UK. I make videos about software development to help developers with the skills they need to be senior developers. As well as this CZcams Channel, I also write articles on my website (alexhyett.com) and write a regular newsletter that contains some thoughts to help aspiring developers.
‼️ DISCLAIMERS
Some of the links in this description are affiliate links, for which I get a small commission, at no extra cost to you 🙂. I appreciate you supporting my channel so I can continue providing you with free software development content!
#coding #programming #developer - Věda a technologie
This is totally brillant....short and concise and really understandable! Top class this!
Thank you Andrew!
This is good. I'm glad you explained the huge benefit of interfaces at the end: makes everything testable. Code covered by tests can be modified and refactored safely, which makes the code easier to maintain in the long run (the purpose of good design).
Finally I understood all of the SOLID principles. Thank you a lot
Just came here to say hello from brazil! I've started moving careers to data science and your videos are so well written and the content so well explained that I've been binge watching them! thank you for posting.
That’s awesome thank you!
This has been by far the best video explaining SOLID Thank you so much! I love the stack and heap memory video too. Keep it up!
Thank you!
I wouldn't say that the SOLID principles are too vague to be useful but I do agree that they are very abstract. I've come across many developers who know what the principles say but they don't really use them because they don't know when they should be using them or how to translate them into code. Maybe we need a set of more concrete principles to fill that gap.
I jumped from game dev to web dev and I can say, I never meet any web dev that actually has the criteria to apply the principles. It's funny because they can recite the principles well, but then the code is never abstracted. They always 'just add another serivce.'
The best tutorial about OOP I have seen so far. Thank you Alex! Also these animations are awesome
Wow, thanks! I am glad you like the animations.
Thank you very much it helped a lot to comprehend sense of all of principles
You're welcome! I am glad it was helpful
Thanks for the video dude, rly great explanation!
Thank you! I am glad you liked it.
Clear, succinct, snappy. A really nice refresher. Thank you
You're very welcome! Thanks for commenting!
Hi Alex. This was brilliant, and in only 7 minutes. Thanks man
I've herd these explained by many people. Yours amongst the cleanest and simplest, also shortest. All these making for a top-notch explanation. :)
Thank you! I don't like to waffle.
Best video about SOLID principles for OOD (OOP)
Brilliantly elaborated... Thank you Alex!
You’re welcome!
clear and amazing ! thanks a lot Sir !
Clear & Concise !!
Your conclusion is absolute important.
100%, SOLID isn't going to fix bad code, and it is easy to write good code without using SOLID. Thanks for commenting :)
You are an Amazing tutor!
Extension methods are the closest thing that C# has to traits. Hopefully, we will have more universal extension in an upcoming version, as Mad Torgersen and Dustin Campbell demonstrated at Build 2023. But still, if you are looking for changing behavior at runtime, then the decorator pattern is the one. Btw. Forwarding stuff to another class is an example of indirection. One should be careful of that. Not to do it just because.
Thank you for your content!
You’re welcome! Thank you for leaving a comment!
Great explanation , within just 7 minutes !!!!
Super nice and easy to grasp. Thank you.
Beginner here, thank you for dumbing it down for me to understand!
Very useful content, Keep it up 👍
Thanks, will do!
Great work. I took hours to read about these 5, barely learned them, then promptly for got them a little while after. It all came back super quick and I think I learned them much better after watching this video.
Thank you, I am glad it helped as refresher.
The best explanation I ever heard. Man, you are great! Keep up the great work 👏.
Thank you! 👍👍
Easiest LSP explanation ever. Thank you.
Glad it helped! Thanks for commenting!
Very good explanation i understood everything great video.
We actually have a dude in our project that brought this SOLID up to a single line. Explosion of interfaces, ununderstandable and not needed abstraction layers and general confusion - that's what we got as a result.
BUT, we also get very very nice skeleton to build on top of. Especially - when it comes to Repository that we actually used. We have 2 entirely diffrent databases (firestore and mongo) and one in-house implemented (by a humble author of this post) in-memory DB mocking the firestore behaviour. So we really can simply mock any behaviour we want, and the most common dependency to the DB is simply non-existent. We simply change the implementation to "mock-db" and define whatever we need for the test. Exchange to MongoDB was also very simple in comparation to what it could have been without having extracted right interfaces...
But...
One have to admit - it has taken a LOT of work to bring the code to this level. Probably any of those issues might have been solved in less time simply by brute-forcing code edition. :>
Yes swapping out a DB for a mock DB is a good use case.
Bro, You got teaching skills. Nice!!!
Thank you! I try my best!
I wouldn't say that "interface" in interface segregation is about C# or Java interfaces. Simply that you should segregate the interface for your class. It could be an interface, but not necessarily. So I try to keep it a language neutral term. Keep up the good work! I find it great.🙂
Yes indeed, I believe the original paper was for C++ and the interfaces he was referring to were abstract classes.
very clear explanations
In the context of the Interface Segregation Principle (ISP), when we refer to a "client," we're talking about a class, module, or component that uses or depends on an interface, not a class that implements the interface.
ISP states that clients should not be forced to depend on methods they do not use (call / invoke). If a class has three methods but the client only calls one of them, the client still has a compile-time dependency (due to the import statement) on the other two methods. The methods could be: retrieve(), save() and delete(). If the client code only calls save(), then it is cleaner for the client code to depend on a 'Saver' interface, rather than the concrete class which implements all three methods.
Also, it is easier to use simple interface both on the caller's (client) side and on the implementation side.
Yes, that is a good point. There appear to be 2 ways to interpret ISP with the internet being split on which one to use. You are right, the original paper does state it is to make life simpler for clients by only including methods used by that client in the interface.
Of course, this does depend on who the client is and whether it is part of your codebase. If the client is unknown the only way to satisfy this version of ISP is to have one method per interface which is obviously an anti-pattern.
Either way, keeping interfaces as small as possible and avoiding fat interfaces is always good practice.
I managed to find the original paper if anyone is interested in reading it:
web.archive.org/web/20150905081110/www.objectmentor.com/resources/articles/isp.pdf
It seems to be a common misconception. Even some articles on the Microsoft website get it wrong:
learn.microsoft.com/en-us/archive/msdn-magazine/2014/may/csharp-best-practices-dangers-of-violating-solid-principles-in-csharp#the-interface-segregation-principle
Please cover CUPID, this was a really good talk and I'd love to see this through the CUPID lens :). I've just seen the "CUPID for joyful programming" talk and really liked it, thank you for that recommendation!
Will do! It’s on the list
One of the best explanations of the SOLID principles!
Thank you!
You missed the opportunity to say solid explanation!
nice && concise.carry on.
Thank you!
@@alexhyettdev Just for clarification to achieve "S" its better to divide interface by feature of my app.
like:
- generating pdf (all methods for generating pdf would be in the interface)
or - say like for one for sending event & another for consuming event in event base architecture.
!!
It's very very very understandable. The example with child-parent-human is very smart and simple )
Thanks 🙏
For decorative pattern , instead of using it can't we just copy code and modify , in what scenario does it help 🙂, I couldn't get clarity in this part
Yes you could do that but it would be breaking the Don’t Repeat Yourself principle. If the code needs to be vastly different then copying is fine. It’s to avoid the case of updating one part but forgetting the other part that got copied.
It is mainly for when you need to add a small piece of functionality (before or after original implementation) that doesn’t apply to every use case. Therefore you avoid breaking existing callers of the method but make use of not duplicating the code.
Thanks!
That BTTF display at the back was so distracting cause it makes me want to buy one and I couldnt stop staring at how cool it is!
My wife bought me that. It is awesome. It is just a light, I wish it was a working clock. I may have to make one at some point...
Thanks so much, I don't understand english very well. However, I really figured out your explanation and gained more one follower.
That's awesome, I am glad I helped.
Great video .. thank you 😊
You’re welcome 😊
Great!
Btw man - do you mind explaining CI & CD in one of your future videos? Would love that!
Yes no problem will add it to the backlog!
@@alexhyettdev great!
Here you go 😉 czcams.com/video/p3W2XCD3smk/video.html
@@alexhyettdev damn that's super lovely! Thank you for getting back here, dude!
this guy is so awesome he explaiend stack and heap in suck a way ill remember forever
Thank you! I am glad I could help.
4:58 addressing the issue i have right now
Just some friendly feedback. Really well written and narrated. BUT your code presentations were far too quick/short giving hardly any time to digest. Users generally hate pausing and rewinding. Maybe less shots of you and your face, leaving the code up longer. From an adult education perspective this would be a lot better. Not everyone has the same processing speed. Also, if you kept it this short because of algorithms etc, be mindful of whose needs you are really trying to meet: your consumers, yours or CZcams's....
Thanks for the feedback, I will try and keep the code up for longer. I don’t intentionally try and keep the videos short. It is just how long they tend to come out when I am recording them.
for me rewinding or pausing is part of learning from videos, also shorter vidoes help alot to motivate me to consume them
Indonesian spokeswoman said : Soliiiid?
Easiest SOLID explanation, especially SRP. Too many others parrot abstract concepts without a concrete example.
Thank you! I am glad you liked it. Yes I don’t think they really understand them when they do that.
06:37 "The code is more what you'd call 'guidelines' than actual rules." - Captain Barbossa, Pirates of the Caribbean
I always find single responsibility principle problematic when it comes to OO design. People end up moving away from "it is" classes to "it does" classes. This reduces "it can be reused".
Here are the principles and here is a class. I have no classes!
Yes the SOLID principles are mostly for OOP languages such as C# and Java. Some of them are still useful for other languages though.
As a beginner programmer, I found your video much clearer than the others I've watched on the SOLID principles.
One thing I'm still unsure about, should child classes implement all arguments defined in the constructor of the parent class? (I guess that would belong to the Interface Segregation part)
E.g. (don't mind the made up syntax)
ParentClass:
constructor(a, b, c = true, d = false):
self.a = a
self.b = b
self.c = c
self.d = d
ChildClassA extends ParentClass:
# doesn't define a new constructor and uses
# all the arguments of the parent's constructor
ChildClassB extends ParentClass:
constructor(a, b, e):
super.constructor(a, b)
self.e = e
Does the fact that arguments 'c' and 'd' are unused in ChildClassB break the SOLID principles?
I don’t see a problem with this. The SOLID principles only really occur once an object has been created.
As long as your child class can still do everything that the parent can it won’t break the LSP.
I think the only time I would be worried about constructor arguments is if the order is implied somehow and missing one out will cause confusion.
e.g.
ParentPosition(x, y, z, t)
ChildPosition(x, z, t)
Without looking at the constructor definition you would assume the child would be (x, y, z)
@@alexhyettdev Great! Thanks a lot for your reply and good point on the arguments' order.
last minutes hillarious😅
Best explanation of solid I've seen. thanks.
Thank you! I am glad it was helpful. Thanks for leaving a comment 👍
The open closed principal is the only one that I don't think is realistic. Basically the way I understand it is once your write code it becomes untouchable. You can only add to it but coding around the original implementation by using extension methods or new implementations of the original interface.
I think it makes sense if your code is being published as part of library for others to use. You wouldn't want to introduce bugs into trusted code. If you are working on a closed source application in a small team then I can see it being unrealistic.
I guess the better approach is to think, "how can I design this, so I won't need to change the interface in the future?"
This is a SOLID video on S.O.L.I.D!
Thank you!
you are amazing
best video for SOLID
Thank you Yazan! I am glad you liked it 👍👍
It'd be great if you write code while explaining.
Thanks for the feedback. Yes I can definite do that more often.
I don't have that feeling, for me everything was understandable here
@3:51 Mom class is hot AF
😂
I don't want to argue against SOLID principles because I can't say I completely and fully follow every rule. However, extending classes to avoid changing them sounds like a long term recipe for disaster. A codebase I once worked had a main class for a product with a ridiculous amount of additional classes that extended it for all kinds of functionality that was introduced over time. It quickly became a huge mess. I argue that there are absolutely moments where a class can and should be changed.
It seems to me many of these principles are designed to help prevent a developer from stepping on their own toes. I argue people should pay closer attention to what they're doing and if they don't understand the code they're changing, they're doomed to make mistakes. They need to understand the code! It's like a mechanic modifying a car without knowing how the engine truly works, IMO. You're doomed if that is the case.
How to be worst programmer principles
Some of them have merit but if you follow them religiously you can end up writing words code definitely.
@@alexhyettdev I'm following get the job done principle using C or C++ unsafe and fast code using SIMD and data oriented design
Why wouldn't you make parent inherit from child in your example... problem solved.
not exactly a beginner friendly content. Other's have done a better explanation
Going a bit too fast. But good info otherwise.
Thanks, yeah still trying to find the right balance. I have a tendency to talk to faster when in front of a camera 🤦🏻♂️.
your git commit... //my code is more important than yours... jajajaja