SOLID Principles: Do You Really Understand Them?

[@martynasgoberis2601]

I got Alex's course on SOLID, and it is just brilliant (wish I had lecturers like this in university :/). Goes more into detail on how to execute these principles in practice.

[@alexhyettdev]

Thanks Martynas, I am glad you like my course, it is really nice to hear!

[@prateekdalmia9400]

Hi where did you get the course from

[@martynasgoberis2601]

Dometrain. It's not free but the quality is very good of all the courses there.

[@prateekdalmia9400]

​@@martynasgoberis2601 thanks buddy

[@andrewmarshall195]

This is totally brillant....short and concise and really understandable! Top class this!

[@alexhyettdev]

Thank you Andrew!

[@residentorangejuice]

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.

[@alexhyettdev]

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

[@togofar]

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.

[@fludeo1307]

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

[@hyperborean72]

Finally I understood all of the SOLID principles. Thank you a lot

[@sanyaua4074]

no you didnt)

[@elvikingo]

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

[@victorialacerda6919]

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.

[@alexhyettdev]

That’s awesome thank you!

[@seijumimurasakibara5516]

i was so scared when i saw liskov, but the way you explained it assauged those fears. I thought it was hard to understand, but you sum it up quite nicely. As a budding developer, thank you very much for this!!

[@criticalthinker1123]

if you really grasped, then give clear example without google?

[@goisenate]

Good explainer, thanks. As for the part about "following the SOLID principles to the letter", the strategy I use in my trainings is this: learn TDD without mock frameworks and then SOLID pops out automatically. For example, if you design a large interface then a mock framework will make it easy to use it in your tests. However, if you do it manuall you will feel the pain of creating an implementation with usesless methods. This pain means your tests want to tell you something about your code design, in this case that you're probably violating the Interface Segregation Principle.

[@rockford717]

Totally agree with the last 2 mins of the video... I think the SOLID is most useful in interviews :)

[@dos328]

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!

[@alexhyettdev]

Thank you!

[@reppair]

I've herd these explained by many people. Yours amongst the cleanest and simplest, also shortest. All these making for a top-notch explanation. :)

[@alexhyettdev]

Thank you! I don't like to waffle.

[@perisicnikola37]

The best tutorial about OOP I have seen so far. Thank you Alex! Also these animations are awesome

[@alexhyettdev]

Wow, thanks! I am glad you like the animations.

[@behehe01]

Thank you so much. The leanest explaination of SOLID I’ve ever learned from

[@jackli1924]

very clear and concise explanations. Thank you so much Alex!

[@kamaleshpramanik7645]

Very short and clear .. Thank you very much Sir.

[@korniszon68]

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

[@alexhyettdev]

Yes swapping out a DB for a mock DB is a good use case.

[@mattedge333]

Clear, succinct, snappy. A really nice refresher. Thank you

[@alexhyettdev]

You're very welcome! Thanks for commenting!

[@llott88]

06:37 "The code is more what you'd call 'guidelines' than actual rules." - Captain Barbossa, Pirates of the Caribbean

[@bubumimo]

Your conclusion is absolute important.

[@alexhyettdev]

100%, SOLID isn't going to fix bad code, and it is easy to write good code without using SOLID. Thanks for commenting :)

[@leezhenjian7451]

Beginner here, thank you for dumbing it down for me to understand!

[@acupsf]

One of the best explanations of the SOLID principles!

[@alexhyettdev]

Thank you!

[@petiks6391]

You missed the opportunity to say solid explanation!

[@jurkocharczenko4581]

Best video about SOLID principles for OOD (OOP)

[@sobit0ks]

Easiest LSP explanation ever. Thank you.

[@alexhyettdev]

Glad it helped! Thanks for commenting!

[@marna_li]

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

[@alexhyettdev]

Yes indeed, I believe the original paper was for C++ and the interfaces he was referring to were abstract classes.

[@sebon11]

Thanks for the video dude, rly great explanation!

[@alexhyettdev]

Thank you! I am glad you liked it.

[@styreep]

Best guide I found. Thanks

[@dmytrodanko8592]

It's very very very understandable. The example with child-parent-human is very smart and simple )

[@laesponjaloca123]

This is top level explanation. Congrats, sir. Great job.

[@MagoMakes]

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 KZbin's....

[@alexhyettdev]

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.

[@thathue]

for me rewinding or pausing is part of learning from videos, also shorter vidoes help alot to motivate me to consume them

[@acp.masque]

Same here. I was searching for something that I could recommend to some early learners and I ended up with this video. However, the speed of content and the examples were rather quick to be grabbed by a junior. BTW it's pretty good for a quick refresh though. Thanks.

[@sharadregoti7742]

Bro, You got teaching skills. Nice!!!

[@alexhyettdev]

Thank you! I try my best!

[@takatakboy]

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!

[@alexhyettdev]

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

[@ognjenvojnovic9778]

Hi Alex. This was brilliant, and in only 7 minutes. Thanks man

[@funkypopper]

Thank you for your explanation! It helped me understand SOLID a lot.

[@mustafabaki275]

Hey! You just gained another subscriber! Thanks for the wonderful explanation! And you are so right that these principles are just to code better but some people consider them as if it is the constitution :)

[@markhenzel2133]

The SOLID principles are not just a set of casual guidelines; they represent a foundational framework for designing robust and maintainable software systems.

[@smileoez]

Thank you very much it helped a lot to comprehend sense of all of principles

[@alexhyettdev]

You're welcome! I am glad it was helpful

[@simonslater7257]

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!

[@alexhyettdev]

Will do! It’s on the list

[@sameerarasanga8975]

Great explanation , within just 7 minutes !!!!

[@manojaher88]

Thank you for such a great video. Learnt a lot

[@NoahNobody]

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.

[@alexhyettdev]

Thank you, I am glad it helped as refresher.

[@StephanSingh2495]

@4:48 can someone please expain, how the 'notImplementedException' breaks the Liskov principle? Like if a parent class sends the 'notImplementedException' for some function, the child class would do the same? Also is Liskov principle in some way applicable to interfaces and their implementations as well?

[@Collidedatoms]

Because presumably there are other classes that implement the interface that DO implement the methods. So if you sub your class in, it will break because instead of doing something appropriate, it would throw an exception or if you have it empty, do nothing. Liskov says that child classes should be able to do EVERYTHING their parent can do. So if the child throws not implemented, it's not actually able to do that thing. It's a code smell that the interface is poorly designed and should be broken up. It might help to understand that basically an interface is just a class with all virtual methods - that is methods which may or may not have default implementations and which require their child to implement if not. Virtual methods are methods where the binding to functionality is determined at runtime. C++ just lets you do that because it has multiple inheritance. It has - to my knowledge anyway, it's been a while - no "interface" keyword. Instead to do interfaces in C++, you create a class with all virtual methods. C# does because then the compiler can enforce "okay, this isn't actually the kind of multiple inheritance that is bad, this is just simply a mixin (interface where all methods have default implementations and add some functionality) or class with purely virtual methods that can be overridden." C# can make sure you don't actually do multiple inheritance.

[@hristopisarev1827]

The best explanation I ever heard. Man, you are great! Keep up the great work 👏.

[@alexhyettdev]

Thank you! 👍👍

[@sebon11]

Btw man - do you mind explaining CI & CD in one of your future videos? Would love that!

[@alexhyettdev]

Yes no problem will add it to the backlog!

[@sebon11]

@@alexhyettdev great!

[@alexhyettdev]

Here you go 😉 kzbin.info/www/bejne/pmS6Y4t5eZimo80

[@sebon11]

@@alexhyettdev damn that's super lovely! Thank you for getting back here, dude!

[@vishalkarthik.v7209]

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

[@alexhyettdev]

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.

[@osivwiokiti9897]

Best explanation of solid I've seen. thanks.

[@alexhyettdev]

Thank you! I am glad it was helpful. Thanks for leaving a comment 👍

[@AlexKashie]

Brilliantly elaborated... Thank you Alex!

[@alexhyettdev]

You’re welcome!

[@Ne1gh_]

Thanks!

[@hamaed19]

Very useful content, Keep it up 👍

[@alexhyettdev]

Thanks, will do!

[@JDevCode]

Thanks so much, I don't understand english very well. However, I really figured out your explanation and gained more one follower.

[@alexhyettdev]

That's awesome, I am glad I helped.

[@emhyrvemrais7574]

Very good explanation i understood everything great video.

[@MenziManqele]

Super nice and easy to grasp. Thank you.

[@alanchen4257]

Clear & Concise !!

[@craftedbysrs]

You are an Amazing tutor!

[@marna_li]

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.

[@tom111_14]

clear and amazing ! thanks a lot Sir !

[@Treborbobuk]

I don't usually comment, but so many people are saying this is a great explanation of SOLID, yet even though it references C# specifically - when talking about Open/Closed you make no mention at all of Abstract / Virtual or Interfaces, which is a huge omission. Extension methods and decorators are fairly advanced topics and are really not the primary methods of achieving open/closed in C# or many other languages. Abstract classes and virtual methods provide a more straightforward approach to OCP by allowing behaviour to be extended through inheritance (which you'll be doing since SOLID mainly applies to OOP)

[@FrankTheTank-fg3xq]

Also encourage people to not use 'Static' as it prevents faking / MOQing of objects for unit testing and forces methods and classes to implement it for use.

[@mymacaintwag]

Here are the principles and here is a class. I have no classes!

[@alexhyettdev]

Yes the SOLID principles are mostly for OOP languages such as C# and Java. Some of them are still useful for other languages though.

[@punkerIII]

Thank you for your content!

[@alexhyettdev]

You’re welcome! Thank you for leaving a comment!

[@khalidelgazzar]

Great video .. thank you 😊

[@alexhyettdev]

You’re welcome 😊

[@xyyx1001]

Easiest SOLID explanation, especially SRP. Too many others parrot abstract concepts without a concrete example.

[@alexhyettdev]

Thank you! I am glad you liked it. Yes I don’t think they really understand them when they do that.

[@xorazmly]

very clear explanations

[@ehm-wg8pd]

4:58 addressing the issue i have right now

[@_mubir]

nice && concise.carry on.

[@alexhyettdev]

Thank you!

[@_mubir]

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

[@217-sritejrajulu6]

this guy is so awesome he explaiend stack and heap in suck a way ill remember forever

[@alexhyettdev]

Thank you! I am glad I could help.

[@jamestacular]

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.

[@alexhyettdev]

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

[@lysithea9293]

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?

[@alexhyettdev]

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)

[@lysithea9293]

@@alexhyettdev Great! Thanks a lot for your reply and good point on the arguments' order.

[@naufalikhlasksatria9228]

Indonesian spokeswoman said : Soliiiid?

[@testingfsqc]

This is a SOLID video on S.O.L.I.D!

[@alexhyettdev]

Thank you!

[@mj65535]

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

[@KaznarahAndrinarivo]

Thanks 🙏

[@eio4528]

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.

[@yazanmansour1231]

you are amazing best video for SOLID

[@alexhyettdev]

Thank you Yazan! I am glad you liked it 👍👍

[@SamaC713]

What is a “class’

[@mariyakulidzhanova7082]

Class is some template that all objects implement. Classes can have properties and methods. For ex. if you want to create a 'Human' object, you need a class that contains 'name', 'age' etc. properties and methods like 'eat()', 'walk()' etc.

[@Iridium.]

So much easier when it’s not game programming related .

[@terry-]

Great!

[@nooruddinraotiwala353]

last minutes hillarious😅

[@technicaltheb034]

It'd be great if you write code while explaining.

[@alexhyettdev]

Thanks for the feedback. Yes I can definite do that more often.

[@sebon11]

I don't have that feeling, for me everything was understandable here

[@SeriousCat5000]

@3:51 Mom class is hot AF

[@alexhyettdev]

😂

[@christopherjackson4924]

😂 lmao. I read this confused before the mom class was made. Now I understand.

[@nishantrai982]

you look like deadpool

[@alexhyettdev]

Hopefully more like Ryan Reynolds than Wade Wilson after turning into a mutant 😂

[@alanjohnson7374]

Why wouldn't you make parent inherit from child in your example... problem solved.

[@chhitijbhattachan3371]

😂

[@sanyaua4074]

smoothie drinker)

[@ClifCollins-k8d]

"I noticed you're still working with polymers." The organization of "functions" is not the basis for logic. Functions should not be used to develop applications. Having billions of single-points-of-failures is not a technology. We should not be programming using a set of (just) hardware instructions grouped in a small number of statements as: functions, subroutines, macros, methods, event handlers, interrupts, message handlers, classes, etc.. Think of ways to not use "functions". It can be done.

[@siddhanttripathi5224]

why does 99% people give the same exact same example over and over to explain these principles why can't they do some real practical type example

[@PopLucian90]

Going a bit too fast. But good info otherwise.

[@alexhyettdev]

Thanks, yeah still trying to find the right balance. I have a tendency to talk to faster when in front of a camera 🤦🏻‍♂️.

[@anlcangulkaya6244]

How to be worst programmer principles

[@alexhyettdev]

Some of them have merit but if you follow them religiously you can end up writing words code definitely.

[@anlcangulkaya6244]

@@alexhyettdev I'm following get the job done principle using C or C++ unsafe and fast code using SIMD and data oriented design

[@DarshitGupta-kf8oc]

why insert background music? Its distracting.

[@sidekick3rida]

God, Java has to be one of the most poorly designed, yet ubiquitous languages

[@FaizKTG]

This is the stupidest most useless set of "principles" and I'm tired of people saying otherwise.

[@DoctorMoax]

not exactly a beginner friendly content. Other's have done a better explanation

[@Pugly-q4n]

The examples given here and elsewhere are too vague - using an actual human child and parent is an incorrect example. The fact is, you have to go to a made up scenario to give any example of Liskov. I challenge anyone here to give me one real-world example of Liskov that would be necessary in real life.

[@charlitowashere5906]

your git commit... //my code is more important than yours... jajajaja

[@bkej420]

SRP explained wrong - again.

[@projectverna1937]

Explain how

[@bkej420]

@@projectverna1937 SRP comes from Robert C. Martin. He explains in his books, that rules states, that a module should be responsible to one, and only one, actor (not as defined like in Actor-Model, but like Actor in UML). In this video it is explained like responsibilites are just different features. Which is plain wrong explanation and it increases confusion around the topic further.