Thanks Ilia, yeah last time was rough. The organizers were pretty crappy and they also castrated me on timing, because I was the last speaker on the list. Maybe next time I'll do it better
Hey man. Thanks for the effort of making attempt on SOLID in GO. Anyway, you did some mistakes: With the Single Responsibility Principle, you correctly split the responsibility of computing and printing, but right away you broke it - Outputting is one responsibility, formatting is yet another one. Not to mention that your Ouputter has two methods: Text and JSON which breaks the Single Responsibility Principle again. Why this is bad? Because you can have multiple output targets: console, file, some device, and multiple formats: YAML, JSON, text, and then to get the desired combination you'll need to create 3x3 methods. When doing solid you should go with 6 simple structs that can be combined in any way you need. Some might say - "why so many structs?", but when you need to pass it to another method/function you will pass only two interfaces. This will help avoid switches and ifs control statements inside of the method/function body to figure out which method you should call. This code will be super easy for unit testing and maintenance. With the Open-Closed Principle, you forgot to mention struct encapsulation. No other implementation should be closed on public properties values since they might change. The problem here is that some classes could write to public property, making the internal state of this object inconsistent, which will affect the behavior in an undesired way. With the Interface Segregation Principle, your "object" interface breaks this principle - it should have only the "volume" method signature. You probably did this mistake, by creating a not logical method "areaVolumeSum" - what it should model in the real world? When you would have "areaSum" and "volumeSum" functions you'd probably make a proper split of interfaces. This is also the reason that interfaces should be created first - to not be biased by already created usage. If you have a sphere struct and you need it only for volumeSum, why also implementing the area method which you don't need? The Dependency Inversion example is good, but the example required to be fixed is not full. To make it full you'd need to implement "NewUserRepository" function where a new instance of MySQL DB is created. An example of fixing it would require this function to take the interface of DB as an argument and set it as a value of a new object of this struct. PS. I want to congratulate you on your presentation skills. They're top-notch.
Wow, for a long time SOLID did not make sense to me. Today it has made total sense. Moving forward I will make use of all these principles. GOOD JOB. ALWAYS.
Great explanation bro... We can use these principles to make clean architecture like in rest API we can eliminate the dependency on the router we use, it can be chi, mux, or anything. Likewise, a database can be MongoDB, Postgre or InMemoryDB.
Very nice video! It would be nice to see you implement these principles in a more complex example. Maybe a tutorial on building a go rest api using solid principles!
@@SteveHook Hey Man, Great work, Just wanted to follow up on this thread, any plans for the REST API videos , where we can see the extensive use of these principals in action, I know, a lot will come when we would apply these in real projects, but still would love to follow if you have something in pipeline as mentioned above.
@@SteveHook thanks, have clicked on thr bell icon! Btw, to add there is code-gen swagger which generates the sever stub , a lot is taken care by simple swagger generation, but i guess it might be complex for other to understand, simple mux or gin framework would work, more focus is on understanding the SOLID in action, i am new to design principles and trying to find some better resources. I can write code but i want to write better easy to read and maintainable code.
just amazing !!! but background music made it go faster....(sometime it feels like concept will go away with background music & i will not be able to grasp it😅).
glad i searched "go solid principles." perhaps you could make some videos on go antipatterns, io writer and reader, other common/interesting parts of the standard library, when to implement an interface (like if you only have 1 type that implements your interface you probably don't need an interface. and the more methods an interface has, the less likely it is that there will be multiple types implementing it) , anything you personally found challenging related to go. just some ideas i think would be helpful as a go developer and trying to become more intermediate as opposed to beginner
I should definitely do. I received more requests about SOLID in more details and should come up with a schedule so they make it in my videos. Glad you found the channel 🥳
@@SteveHook that would be great! reviewing the open/closed principle, i thought OH MY we, including our senior engineers, do not implement that very often...
Just FYI guys, I thought of doing a web dev series. Instead I am currently working on a Udemy course that’s gonna be big and comprehensive with lots of surprises and at a high quality as usual. So stay tuned. It’s coming up in couple of months 😊
Hi man, it’s multiple sources depending which one gives me a better option. I guess I should link them in description. So it’s EpidemicSound, Envato Elements and SoundSnap
Hey Steve, thanks a lot for the great video. Learned a lot in a short time. May I ask you what vscode extension you use to get the interfaces show under the structs?
@@SteveHook right, I don’t know why I assumed you use vscode. Sure, if I find anything similar I’ll let you know. That’s a cool feature to have. Not knowing which struct implements which interface is one area that makes it difficult to work with object oriented design patterns in golang. When I saw you had that feature I was very excited.
In Go you don’t need to know who implements what. Everyone implements at least interface{}. But it’s a nice way of seeing usages in the code, especially when working in a big project 👊
I'm not yet "solid" with solid : isn't it a break of the open/close 2nd principle, in the last principle example ? "... switch res.(type) { case map[string]string: ..."
So, I used the type assertion in that specific case to simulate a real MySQL / Postgres driver, they normally return different types, which is why I needed the type assertion. Ideally receiving a specific interface would have solved the problem. P.S. next time specify the timestamp from the video. Don't make me go through the pain of watching my own video again 😂
Your take on SRP is not correct - A function should only do one thing but this is not the SRP. Uncle Bob's final version, from his book Clean Architecture is "A module should be responsible to one, and only one, Actor". Good video though...!
That is exactly was I was to clarify, SRP (The Single Responsibility Principle) talk About "... each software module has only one, and only one, reason to change." And it is not about what it does as functionality!. Fortunately, the implementation is Fine!, but what it is mean? if you are going to modify your module as @Steve Hook mention in the video the same module function has two reasons to change (format the output [1] and calculate the result [2]), so if you want to improve/change some of both, you are broken the SRP.
@@christiangda Uncle Bob updated the meaning of the SRP.... Remember we are talking about the module NOT the function. The word cohesive implies the SRP. Cohesion is the force that binds together the code responsible to a single actor - Clean Architecture pp 63 Robert C Martin.
I think we should clarify what a module really is. A module in software in general is not tied to or necessarily related to the definition and implementation of the module each language and ecosystem has. It rather refers to a piece of executable code that is meant to be run/called by the main or other parts of the program. Be it a function/method/type/module and others. They are all part of the same SRP definition just at a different scale. And IMHO the module word kinda describes all of them in one word perfectly. Hope that clarifies my examples and explanation
Steve Hook We have to be careful on this.... going down too far will result in brittle tests. The idea that a module will be responsible to one actor is a delicate balance!
Dude, thanks for the video, but why you are talking so fast and with lots of pressure? Isn't it important to explain clearly, instead of talking uncomfortably?
Thanks, I had my doubts about Go you sold me on the last MDC :) Keep up the videos, good stuff
Thanks Ilia, yeah last time was rough. The organizers were pretty crappy and they also castrated me on timing, because I was the last speaker on the list. Maybe next time I'll do it better
@@SteveHook Yeah, a pity. It was really interesting, I got furious because of them. That was rude.
One of the best explanations of SOLID I've seen. Concise but complete. Kudos for speaking quickly; no need to watch your vids at 2X speed!
Thanks mate, should come up with some bigger examples
Voila that is the most impressive video tutorial about solid in golang😁😜
Thanks a lot buddy 🥰🥰 I guess an update is required 😋
So clear, so concise, better can't be : you're the king !
😄😄 I’m trying
I have been doing all this without knowing about the SOLID acronym. Nice video btw.
Great explanation in short clips. You clarified the concept in very simple and straight forward examples. Thanks pal, senpai rather!
Thank you so much Lance, glad you enjoyed this 💪
Hey man. Thanks for the effort of making attempt on SOLID in GO. Anyway, you did some mistakes:
With the Single Responsibility Principle, you correctly split the responsibility of computing and printing, but right away you broke it - Outputting is one responsibility, formatting is yet another one. Not to mention that your Ouputter has two methods: Text and JSON which breaks the Single Responsibility Principle again. Why this is bad? Because you can have multiple output targets: console, file, some device, and multiple formats: YAML, JSON, text, and then to get the desired combination you'll need to create 3x3 methods. When doing solid you should go with 6 simple structs that can be combined in any way you need. Some might say - "why so many structs?", but when you need to pass it to another method/function you will pass only two interfaces. This will help avoid switches and ifs control statements inside of the method/function body to figure out which method you should call. This code will be super easy for unit testing and maintenance.
With the Open-Closed Principle, you forgot to mention struct encapsulation. No other implementation should be closed on public properties values since they might change. The problem here is that some classes could write to public property, making the internal state of this object inconsistent, which will affect the behavior in an undesired way.
With the Interface Segregation Principle, your "object" interface breaks this principle - it should have only the "volume" method signature. You probably did this mistake, by creating a not logical method "areaVolumeSum" - what it should model in the real world? When you would have "areaSum" and "volumeSum" functions you'd probably make a proper split of interfaces. This is also the reason that interfaces should be created first - to not be biased by already created usage. If you have a sphere struct and you need it only for volumeSum, why also implementing the area method which you don't need?
The Dependency Inversion example is good, but the example required to be fixed is not full. To make it full you'd need to implement "NewUserRepository" function where a new instance of MySQL DB is created. An example of fixing it would require this function to take the interface of DB as an argument and set it as a value of a new object of this struct.
PS. I want to congratulate you on your presentation skills. They're top-notch.
solid is just kilometers of unesseary abstractions
@@sigmawolf228 which can save a lot of time especially for the new comers working on a large project
Wow, for a long time SOLID did not make sense to me. Today it has made total sense. Moving forward I will make use of all these principles. GOOD JOB. ALWAYS.
Thanks a lot buddy, hope it helped 🤗
great work on this Steve, looking for more videos
Thanks a lot sir 🥰🥰
Thank goodness. I get how to apply the principles.
Bravo !!! I thought for one second as a newbie that golang would be limited for conception, but boy I'm so glad that I was wrong !
Yeah, still my favorite language ❤️❤️
Great explanation bro...
We can use these principles to make clean architecture like in rest API we can eliminate the dependency on the router we use, it can be chi, mux, or anything. Likewise, a database can be MongoDB, Postgre or InMemoryDB.
Thx mate, yeah. I guess this principle needs an updated video
Very nice video! It would be nice to see you implement these principles in a more complex example. Maybe a tutorial on building a go rest api using solid principles!
💯 agree man, that video series it’s coming up. So many plans, and so much work. Stay tuned, I’ll keep ya posted
@@SteveHook Hey Man, Great work, Just wanted to follow up on this thread, any plans for the REST API videos , where we can see the extensive use of these principals in action, I know, a lot will come when we would apply these in real projects, but still would love to follow if you have something in pipeline as mentioned above.
Sure man. Planning to roll out some of them soon
@@SteveHook thanks, have clicked on thr bell icon! Btw, to add there is code-gen swagger which generates the sever stub , a lot is taken care by simple swagger generation, but i guess it might be complex for other to understand, simple mux or gin framework would work, more focus is on understanding the SOLID in action, i am new to design principles and trying to find some better resources. I can write code but i want to write better easy to read and maintainable code.
Stay tuned my friend 😉
Man you keep improving! you have earned the sub! =)
Thanks man. Guess what there’s room for more improvement
Simply Superb
Thanks a lot 🥰
Great one.
Thx
Absolutely amazing explanation! Simple, clear and on point! Thanks man! subscribed:)
Thanks mate, glad to hear that 😊😊
good video. keep make this awesome video. refresh video.
Thanks, will definitely do
Enjoyed ur content a lot . Was understandable and quite amusing at the same time 😁👍
Great explanation! After watching your videos, I have started to watch other videos at a fast speed. :)
Gotta admit though I kinda was rushing back them in those videos 😂😂😅
just amazing !!! but background music made it go faster....(sometime it feels like concept will go away with background music & i will not be able to grasp it😅).
Amazing
Thx ☺️
Great explanation
Thx mate ☺️
Thx mate ☺️
very good and informative. excellent examples.
Thanks mate, glad u’re enjoying it 😊😊
Awesome explanation! Thanks, Steve.
Thanks mate, hopefully I come with an updated version or smth ☺️
Thanks!
You’re welcome ☺️
That one was really good! Thank you for sharing)
You’re welcome 😎
Brilliant presentation. Had to subscribe. Peace!
Thx mate
bruh only 3k suscribers, why? Where have you been all this time? Suscribed!
Thanks man, idk. Guess I need to put in more work
Nice simple clear explanation.
Thanks mate, glad it was useful
Man I”m kearning so much from your vids! Sub
Thanks, glad you are enjoying them
glad i searched "go solid principles." perhaps you could make some videos on go antipatterns, io writer and reader, other common/interesting parts of the standard library, when to implement an interface (like if you only have 1 type that implements your interface you probably don't need an interface. and the more methods an interface has, the less likely it is that there will be multiple types implementing it) , anything you personally found challenging related to go. just some ideas i think would be helpful as a go developer and trying to become more intermediate as opposed to beginner
I should definitely do. I received more requests about SOLID in more details and should come up with a schedule so they make it in my videos. Glad you found the channel 🥳
@@SteveHook that would be great! reviewing the open/closed principle, i thought OH MY we, including our senior engineers, do not implement that very often...
It happens. In a real world things are not always beautiful and according to principles and best practices
could you please make a series videos for making web application in go
vtvvn ha Sure, got that on my list as well
Here you go - lets-go.alexedwards.net/
Just FYI guys, I thought of doing a web dev series. Instead I am currently working on a Udemy course that’s gonna be big and comprehensive with lots of surprises and at a high quality as usual. So stay tuned. It’s coming up in couple of months 😊
Great video, subscribed!
Glad you enjoyed it 😊😊
Hi bro, great stuff again. 1 question where do you get the sounds from in video editing. Like glass lock cat etc.
Hi man, it’s multiple sources depending which one gives me a better option. I guess I should link them in description.
So it’s EpidemicSound, Envato Elements and SoundSnap
Steve Hook thanks, found some really good stuff there.
Yeah, lots of SFX and Music on those platforms. Forget about the royalty free stuff. Pay a subscription and get everything without a worry
great explanation, but i feel like eminem made a video with coding hahaha
Lol 😂
That thumbnail 😄👌👌👌
Thx man
Great bro thanks
Thanks man
Hey Steve, thanks a lot for the great video. Learned a lot in a short time. May I ask you what vscode extension you use to get the interfaces show under the structs?
Hey Newsha, I mostly use Goland. Not sure VSCode has such an extension, but let me know if you find such a thing 🙂
@@SteveHook right, I don’t know why I assumed you use vscode. Sure, if I find anything similar I’ll let you know. That’s a cool feature to have. Not knowing which struct implements which interface is one area that makes it difficult to work with object oriented design patterns in golang. When I saw you had that feature I was very excited.
In Go you don’t need to know who implements what. Everyone implements at least interface{}. But it’s a nice way of seeing usages in the code, especially when working in a big project 👊
I'm not yet "solid" with solid : isn't it a break of the open/close 2nd principle, in the last principle example ?
"...
switch res.(type) {
case map[string]string:
..."
So, I used the type assertion in that specific case to simulate a real MySQL / Postgres driver, they normally return different types, which is why I needed the type assertion. Ideally receiving a specific interface would have solved the problem.
P.S. next time specify the timestamp from the video. Don't make me go through the pain of watching my own video again 😂
@@SteveHook THANKS Steve !
I'm watching some of your videos several time and it's never painfull for me ;-)
Kidding, I just happen to be sick of watching me after a whole cumbersome editing session 😂 editing myself isn’t an easy thing
What’s your viscose theme?
I am using Goland with Material Theme + Atom Icons 😉
awesome stuff but slow down dude lol!
Thanks bruh!
You’re welcome mate
Your take on SRP is not correct - A function should only do one thing but this is not the SRP. Uncle Bob's final version, from his book Clean Architecture is "A module should be responsible to one, and only one, Actor". Good video though...!
That is exactly was I was to clarify, SRP (The Single Responsibility Principle) talk About "... each software module has only one, and only one, reason to change." And it is not about what it does as functionality!.
Fortunately, the implementation is Fine!, but what it is mean? if you are going to modify your module as @Steve Hook mention in the video the same module function has two reasons to change (format the output [1] and calculate the result [2]), so if you want to improve/change some of both, you are broken the SRP.
@@christiangda Uncle Bob updated the meaning of the SRP.... Remember we are talking about the module NOT the function. The word cohesive implies the SRP. Cohesion is the force that binds together the code responsible to a single actor - Clean Architecture pp 63 Robert C Martin.
I think we should clarify what a module really is. A module in software in general is not tied to or necessarily related to the definition and implementation of the module each language and ecosystem has. It rather refers to a piece of executable code that is meant to be run/called by the main or other parts of the program. Be it a function/method/type/module and others. They are all part of the same SRP definition just at a different scale. And IMHO the module word kinda describes all of them in one word perfectly. Hope that clarifies my examples and explanation
Steve Hook We have to be careful on this.... going down too far will result in brittle tests. The idea that a module will be responsible to one actor is a delicate balance!
I’ll be glad to perhaps make another video where I dive deeper into each and everyone of them. Otherwise it creates confusion for those who watch
👍💪👍
Seems like a good way to 10x the amount of code, and make it harder to understand. Flexible, sure. Easy to read? not so much.
do you have any paid courses?
Not yet, but hopefully will
Dude, thanks for the video, but why you are talking so fast and with lots of pressure? Isn't it important to explain clearly, instead of talking uncomfortably?
I guess I tried to fit in 5 mins, which I never do 😅
@@SteveHook Why? Is anybody or TH-cam forcing you to do it in 5 minutes?
Noted for future 😉
@@SteveHook Thanks man! :)
My bad is my bad. Always learning how to serve my audience the best way 😉
What a mess. This language needs some syntactic sugar for sure
no,thanks )