The Power Of Golang's Decorator Pattern
Вставка
- Опубліковано 4 лют 2025
- ► Join my Discord community for free education 👉 / discord
► Pre order (get 30% off) my exclusive Golang course 👉 fulltimegodev.com
► Become a Patreon for exclusive tutorials👉 / anthonygg_
► Follow me on Twitter 👉 / anthdm
► Follow me on GitHub 👉 github.com/anthdm
In this Golang tutorial, we'll explore the decorator pattern in Golang, a powerful design pattern that allows you to add new functionality to existing objects dynamically. We'll dive into the details of how the decorator pattern works, its advantages, and how you can use it to improve the flexibility and extensibility of your code. Whether you're a seasoned Golang developer or just getting started, this video is a must-watch for anyone looking to improve their coding skills.
► 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?
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 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: ua-cam.com/video/xyBcoGNGrsI/v-deo.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.
Dude Anthony I'm so happy to have found your channel. Amazing content.
Oh wow, I just relize, perhaps this is best way to reduce boring line to setting callback for each handler. Thanks a lot for the inspiration
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!
The way you show things at real time are so amazing. It teaches a lot.
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.
This is an adapter pattern. Decorator pattern its more about returning entity with the same type, but with additional behaviour.
Bro you rock! Lmao, really love your style and how you always say why and why not to do things without BS! 🤩
So good content. I dont think anyone would explain dependency injection that easy. Even a noob beginner like me could easily understand it.
Thanks!
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
Great video thanks. It's something very common for JS developers I believe.
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”
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
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() }}
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? 😅
Very cool topic. I want to boost my vim like yours, could you tell what plugins you use?
None.
ua-cam.com/video/AzhSnM0uHvM/v-deo.html
As a Pythonista you immediately understand :]
Yup this pattern is good when used sparsely. I made the mistake before of using this everywhere and things quickly spiral out of control.
the keyboard stroks sound is distracting bro, never seen a tutorial like that. can you please consider this in the fututre?
Great stuff! Can you maybe give an example of how to handle an error in myExecuteFunc?
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?
Higher order function 🚀
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
Muscles go hard!
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
Has anyone taken this course? How is it so far?
love u anthony
lovely
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
Ok papi
People for js land, we call it currying 😅
Love your stuff ... BUT stop moving the cursor around when not needed ... it drives me NUTS!!! I cant' watch it
He still calls his ex func... That's sad
🥲
we also need Anthony's muscle pattern
Plzz include k8s deployment as well in the course 😅
I think its better to call this the handler pattern
Yeah, I can feel that. Why not.
Dude, give me your course for free if you're interested 😄
Why `Execute(myExecuteFunc())` and not `myExecuteFunc()()`?
$$$
MyChicken(YourEgg(HisChicken(EggStore))). Now could you tell me, at first glance, which function came first, the chicken or the egg?