► Join my Discord community for free education 👉 discord.com/invite/bDy8t4b3Rz ► Pre order (get 30% off) my Golang course 👉 fulltimegodev.com ► Become a Patreon for exclusive tutorials 👉 www.patreon.com/anthonygg_ Thanks for watching
It's a good pattern to do complex stuff if you need a lot of freedom, but in most cases using function closures everywhere is just an overkill and hard to read/debug. In most cases using a struct with methods that accepts an interface (like DB in this case) is more readable, more logical to grasp and also perfectly doable to test.
Bang on! I'd advocate doing most of the closures stuff around the middlewares and inject an encapsulated struct containing the db, logger and monitoring connections into the request, rather than using closures all over the place. I think the context object is the ideal candidate to extend when it comes to injecting dependency.
@@ragequilt_ Shoving dependencies into context is a nightmare for explicit dependency expression. It's convenient, at the cost of being unclear, hard to contain, and hard to reason about what's in the context and how it's getting there.
@@ragequilt_ @Dozer456123 Not sure where I read this but I remember reading that putting required data into context is an anti-patern. Context is meant to only contain optional values. It can be used to provide contextual information but the program shouldn't crash if something required isn't present in the context. Much better to explicitly pass what you need.
@@robertsteele6415 Could you point me to anything which talks about this. My perspective was largely in the context of the stuff in the video. For ex: An API which is largely request-response doing standard CRUD operations, can pass on the database connection as a context object. A lot of these decision depend on what the application is doing. I don't mean to imply all dependencies should be wrapped up in the context.
This is only a common technique in functional programming called "higher-order function". In Go, it is only useful to extend an existing "black Box Function" which you cannot touch. You simply create a newFunction(), which take the blackBoxFunction() as parameter, do your stuff in your newFunction before (and or after) calling the blackBoxFunction(). FInally, you will use your NewFunction() to replace the blackBoxFunction(). You should not abuse this technique everywhere as he said, because it makes your code harder to read and to maintain (the more higher-order a function is, the harder to understand it). In normal circumstance where you don't have to extend a blackBoxFunction, You should just write normal & idiomatic Go codes: - Concerning the Decorator Pattern, this video show this pattern in idiomatic Go codes, no need to wrap your head around higher-order function: th-cam.com/video/xyBcoGNGrsI/w-d-xo.html - Concerning the "Dependency Injection" it is nothing fancy: Your function require a DB interface as input parameter (your function depends on this input), when you call it, you will provide (so inject) the real implementation of this interface (or a mock implementation to unit test your function).. Everything is normal idiot Go Codes, no need for anything fancy for this kind of "Dependency injection". However in a more complex Go project whose the Dependency Graph is complex, you might need a DI container and a DI Resolver, and there are already some lib providing you these things For eg: github.com/goioc/di or github.com/alibaba/IOC-golang Evens in this scenario your Go Code stays boring & idiot
Ah yes, finally we are getting into software design patterns in the context of Go. Please show some more patterns (e.g. (abstract) factory, strategy, adapter etc.) :)
this is the single most important technique in all of software development. i dont mean the closure where you capture the DB, but rather, the dependency injection and contract based programming (using interfaces to dictate what your injected dependencies can do, you can swap them out easily as you do not care about the actual underlying thing, just that it fulfills the contract outlined in the interface). this is super strong for mocking and testing things! and its super clean because of decoupling! your business logic has nothing to do with any concrete class.. it just requires some interfaces to be fulfilled to be happy!
Add a little WithOptions pattern in there too, you can have 20 steps to through and just straight up inject them anywhere. This is how I write the Validation layer.
Great tutorial, but in my opinion, more concrete examples would be more helpful. It’s easy to get lost in the weeds when the amount of functions starts increasing and they do things like print “FOO BAR BAZ”
I would rather call it a Factory pattern (instead of class for functions) - a function that creates other functions based on parameters. Decorator to me would be more like: a function that takes a function, does something around it or with the parameters and then calls the function. func decorate(t func) func { return func() { print "X"; t() }}
what use cases does the decorator pattern come in handy for? seems like a lot of boilerplate code and I'm not sure i understand yet where this could be applied
Writing - code that has high cohesion and low coupli g - code that adheres to solid patterns - code that’s easily testable as a unit - code that is very modular and easy to change versions. Writing code without patterns can only get you so far before you end up with spaghetti …
Tony GG I'm gonna find myself a lady only to have you be my best man so that I can legitimately pick your brain whenever I want to; your content is amazing, it may take me a week to diggest a vid like this however it is amazing, thanks man
You're wrong, what you've presented is different, it's just a higher-order function. In object-oriented programming, the decorator pattern is a design pattern that allows behavior to be added to an individual object, dynamically. One more item to think about, your solution breaks the Open-closed principle, by adding a new “decorator” you need to refactor the previous chained function
I find your videos very useful. Thank you sharing them. However, your IDE, especially the cursor is bouncing back and forth all the time and it makes it very hard to track. It is too distracting. Maybe it is just me, but wanted to share.
I do like your videos, but this one seems a bit odd to me. First, the naming of your variables and functions is very generic for an example. It would be easier to follow with precise naming. Second, nobody will inject DB methods into a http handler in a real project. Using clean architecture solves this usecase entirely and in a better way. Third, your typing is distracting. You type like 500 characters a minute, but need to correct every third of them. Try to be less error prone in order to let people focus on the topic, not on typing errors. Otherwise, nice videos!
You are doing too much mistypes and cursor movements without reason - it distracts attention and makes difficult to follow the idea. Don't rush :) You can prepare code fragments before recording video and just uncomment nesessary parts during explanation
![BOWKYLION - วิงวอน (ex-change) [Official MV]](http://i.ytimg.com/vi/cLdnZWDaO-w/mqdefault.jpg)
► Join my Discord community for free education 👉 discord.com/invite/bDy8t4b3Rz
► Pre order (get 30% off) my Golang course 👉 fulltimegodev.com
► Become a Patreon for exclusive tutorials 👉 www.patreon.com/anthonygg_
Thanks for watching
It's a good pattern to do complex stuff if you need a lot of freedom, but in most cases using function closures everywhere is just an overkill and hard to read/debug. In most cases using a struct with methods that accepts an interface (like DB in this case) is more readable, more logical to grasp and also perfectly doable to test.
Bang on! I'd advocate doing most of the closures stuff around the middlewares and inject an encapsulated struct containing the db, logger and monitoring connections into the request, rather than using closures all over the place. I think the context object is the ideal candidate to extend when it comes to injecting dependency.
@@ragequilt_ Shoving dependencies into context is a nightmare for explicit dependency expression. It's convenient, at the cost of being unclear, hard to contain, and hard to reason about what's in the context and how it's getting there.
@@ragequilt_ @Dozer456123 Not sure where I read this but I remember reading that putting required data into context is an anti-patern. Context is meant to only contain optional values. It can be used to provide contextual information but the program shouldn't crash if something required isn't present in the context. Much better to explicitly pass what you need.
@@robertsteele6415 Could you point me to anything which talks about this. My perspective was largely in the context of the stuff in the video. For ex: An API which is largely request-response doing standard CRUD operations, can pass on the database connection as a context object. A lot of these decision depend on what the application is doing. I don't mean to imply all dependencies should be wrapped up in the context.
New in functional programming. Can you give an example of the above code using the struct with methods that accepts an interface?
This is only a common technique in functional programming called "higher-order function". In Go, it is only useful to extend an existing "black Box Function" which you cannot touch. You simply create a newFunction(), which take the blackBoxFunction() as parameter, do your stuff in your newFunction before (and or after) calling the blackBoxFunction(). FInally, you will use your NewFunction() to replace the blackBoxFunction().
You should not abuse this technique everywhere as he said, because it makes your code harder to read and to maintain (the more higher-order a function is, the harder to understand it). In normal circumstance where you don't have to extend a blackBoxFunction, You should just write normal & idiomatic Go codes:
- Concerning the Decorator Pattern, this video show this pattern in idiomatic Go codes, no need to wrap your head around higher-order function: th-cam.com/video/xyBcoGNGrsI/w-d-xo.html
- Concerning the "Dependency Injection" it is nothing fancy: Your function require a DB interface as input parameter (your function depends on this input), when you call it, you will provide (so inject) the real implementation of this interface (or a mock implementation to unit test your function).. Everything is normal idiot Go Codes, no need for anything fancy for this kind of "Dependency injection". However in a more complex Go project whose the Dependency Graph is complex, you might need a DI container and a DI Resolver, and there are already some lib providing you these things For eg: github.com/goioc/di or github.com/alibaba/IOC-golang Evens in this scenario your Go Code stays boring & idiot
Great info. You have a blog or something? Love it, bruh - straight to the point, no water.
Ah yes, finally we are getting into software design patterns in the context of Go. Please show some more patterns (e.g. (abstract) factory, strategy, adapter etc.) :)
Owke thats the feedback I need.
+1
Awesome! 😃 Here are some more patterns: factory, strategy, adapter, and more. 🚀
Awesome! 😃 Here are some more patterns: factory, strategy, adapter, and more. 🚀
+1 !
this is the single most important technique in all of software development.
i dont mean the closure where you capture the DB, but rather, the dependency injection and contract based programming (using interfaces to dictate what your injected dependencies can do, you can swap them out easily as you do not care about the actual underlying thing, just that it fulfills the contract outlined in the interface). this is super strong for mocking and testing things! and its super clean because of decoupling!
your business logic has nothing to do with any concrete class.. it just requires some interfaces to be fulfilled to be happy!
Dude Anthony I'm so happy to have found your channel. Amazing content.
The way you show things at real time are so amazing. It teaches a lot.
This is an adapter pattern. Decorator pattern its more about returning entity with the same type, but with additional behaviour.
Add a little WithOptions pattern in there too, you can have 20 steps to through and just straight up inject them anywhere. This is how I write the Validation layer.
Great tutorial, but in my opinion, more concrete examples would be more helpful. It’s easy to get lost in the weeds when the amount of functions starts increasing and they do things like print “FOO BAR BAZ”
So good content. I dont think anyone would explain dependency injection that easy. Even a noob beginner like me could easily understand it.
Thanks!
Great video thanks. It's something very common for JS developers I believe.
Bro you rock! Lmao, really love your style and how you always say why and why not to do things without BS! 🤩
Excellent but why do you type so fast as if some tiger is running behind you?
How do you know there is no tiger behind me? 😅
Higher order function 🚀
I would rather call it a Factory pattern (instead of class for functions) - a function that creates other functions based on parameters.
Decorator to me would be more like: a function that takes a function, does something around it or with the parameters and then calls the function. func decorate(t func) func { return func() { print "X"; t() }}
Yup this pattern is good when used sparsely. I made the mistake before of using this everywhere and things quickly spiral out of control.
what use cases does the decorator pattern come in handy for? seems like a lot of boilerplate code and I'm not sure i understand yet where this could be applied
Every golang http framework is based on this pattern
Writing
- code that has high cohesion and low coupli g
- code that adheres to solid patterns
- code that’s easily testable as a unit
- code that is very modular and easy to change versions.
Writing code without patterns can only get you so far before you end up with spaghetti …
Apart from what was described in the video, when you start unit testing your code, you will realize its power
ah makes sense, thanks
the keyboard stroks sound is distracting bro, never seen a tutorial like that. can you please consider this in the fututre?
As a Pythonista you immediately understand :]
Tony GG I'm gonna find myself a lady only to have you be my best man so that I can legitimately pick your brain whenever I want to; your content is amazing, it may take me a week to diggest a vid like this however it is amazing, thanks man
Great stuff! Can you maybe give an example of how to handle an error in myExecuteFunc?
Very cool topic. I want to boost my vim like yours, could you tell what plugins you use?
None.
th-cam.com/video/AzhSnM0uHvM/w-d-xo.html
Muscles go hard!
love u anthony
I really like your videos, but could you explain a bit more what is happening , how it works, etc + being a little more calm and ordered?
lovely
Where do I find your dotfiles?
Its on my Github. Https://github.com/anthdm/.nvim
Instead of passing writers and readers everywhere it would make more sense to pass a context
Has anyone taken this course? How is it so far?
You're wrong, what you've presented is different, it's just a higher-order function. In object-oriented programming, the decorator pattern is a design pattern that allows behavior to be added to an individual object, dynamically.
One more item to think about, your solution breaks the Open-closed principle, by adding a new “decorator” you need to refactor
the previous chained function
MyChicken(YourEgg(HisChicken(EggStore))). Now could you tell me, at first glance, which function came first, the chicken or the egg?
People for js land, we call it currying 😅
we also need Anthony's muscle pattern
Plzz include k8s deployment as well in the course 😅
He still calls his ex func... That's sad
🥲
I find your videos very useful. Thank you sharing them. However, your IDE, especially the cursor is bouncing back and forth all the time and it makes it very hard to track. It is too distracting. Maybe it is just me, but wanted to share.
Dude, give me your course for free if you're interested 😄
I think its better to call this the handler pattern
Yeah, I can feel that. Why not.
I do like your videos, but this one seems a bit odd to me. First, the naming of your variables and functions is very generic for an example. It would be easier to follow with precise naming. Second, nobody will inject DB methods into a http handler in a real project. Using clean architecture solves this usecase entirely and in a better way. Third, your typing is distracting. You type like 500 characters a minute, but need to correct every third of them. Try to be less error prone in order to let people focus on the topic, not on typing errors. Otherwise, nice videos!
Why `Execute(myExecuteFunc())` and not `myExecuteFunc()()`?
You are doing too much mistypes and cursor movements without reason - it distracts attention and makes difficult to follow the idea. Don't rush :) You can prepare code fragments before recording video and just uncomment nesessary parts during explanation
Ok papi
Love your stuff ... BUT stop moving the cursor around when not needed ... it drives me NUTS!!! I cant' watch it
$$$