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

@alexhyettdev

9 ай бұрын

Thank you Andrew!

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

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

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

9 ай бұрын

That’s awesome 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.

@fludeo1307

5 ай бұрын

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

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

4 ай бұрын

Thank you!

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

@alexhyettdev

4 ай бұрын

You're very welcome! Thanks for commenting!

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

@alexhyettdev

4 ай бұрын

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

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

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

Super nice and easy to grasp. Thank you.

Thanks for the video dude, rly great explanation!

@alexhyettdev

11 ай бұрын

Thank you! I am glad you liked it.

Brilliantly elaborated... Thank you Alex!

@alexhyettdev

6 ай бұрын

You’re welcome!

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

@alexhyettdev

8 ай бұрын

You're welcome! I am glad it was helpful

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

2 ай бұрын

Thank you! I don't like to waffle.

clear and amazing ! thanks a lot Sir !

Great explanation , within just 7 minutes !!!!

Thank you for your content!

@alexhyettdev

11 ай бұрын

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

Very good explanation i understood everything great video.

Clear & Concise !!

Best video about SOLID principles for OOD (OOP)

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

Easiest LSP explanation ever. Thank you.

@alexhyettdev

5 ай бұрын

Glad it helped! Thanks for commenting!

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

10 ай бұрын

Thank you, I am glad it helped as refresher.

You are an Amazing tutor!

Very useful content, Keep it up 👍

@alexhyettdev

11 ай бұрын

Thanks, will do!

One of the best explanations of the SOLID principles!

@alexhyettdev

11 ай бұрын

Thank you!

@petiks6391

8 ай бұрын

You missed the opportunity to say solid explanation!

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

@alexhyettdev

9 ай бұрын

Thank you! 👍👍

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

8 ай бұрын

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

Bro, You got teaching skills. Nice!!!

@alexhyettdev

10 ай бұрын

Thank you! I try my best!

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

5 ай бұрын

Will do! It’s on the list

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

9 ай бұрын

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

very clear explanations

Your conclusion is absolute important.

@alexhyettdev

8 ай бұрын

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

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

9 ай бұрын

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

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.

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

9 ай бұрын

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

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

@alexhyettdev

8 ай бұрын

That's awesome, I am glad I helped.

Great video .. thank you 😊

@alexhyettdev

5 ай бұрын

You’re welcome 😊

Thanks!

Thanks 🙏

nice && concise.carry on.

@alexhyettdev

8 ай бұрын

Thank you!

@_mubir

8 ай бұрын

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

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

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

@alexhyettdev

9 ай бұрын

Thank you! I am glad I could help.

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

9 ай бұрын

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.

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

@alexhyettdev

11 ай бұрын

Yes no problem will add it to the backlog!

@sebon11

11 ай бұрын

@@alexhyettdev great!

@alexhyettdev

10 ай бұрын

Here you go 😉 kzread.info/dash/bejne/omeLlLp8dJbZnc4.html

@sebon11

10 ай бұрын

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

Great!

Best explanation of solid I've seen. thanks.

@alexhyettdev

10 ай бұрын

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

4:58 addressing the issue i have right now

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

10 ай бұрын

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

10 ай бұрын

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

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

@alexhyettdev

9 ай бұрын

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

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

@alexhyettdev

7 ай бұрын

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

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

@alexhyettdev

8 ай бұрын

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

5 ай бұрын

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?

you are amazing best video for SOLID

@alexhyettdev

10 ай бұрын

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

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

@alexhyettdev

5 ай бұрын

Thank you!

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

last minutes hillarious😅

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

7 ай бұрын

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

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

@alexhyettdev

11 ай бұрын

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

@sebon11

11 ай бұрын

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

@3:51 Mom class is hot AF

@alexhyettdev

8 ай бұрын

😂

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

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

@alexhyettdev

9 ай бұрын

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

@anlcangulkaya6244

9 ай бұрын

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

Going a bit too fast. But good info otherwise.

@alexhyettdev

6 ай бұрын

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

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

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

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