The Power Of Golang's Decorator Pattern 

► 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

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: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-xyBcoGNGrsI.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.) :)

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.

Dude Anthony I'm so happy to have found your channel. Amazing content.

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.

The way you show things at real time are so amazing. It teaches a lot.

So good content. I dont think anyone would explain dependency injection that easy. Even a noob beginner like me could easily understand it.

Bro you rock! Lmao, really love your style and how you always say why and why not to do things without BS! 🤩

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”

Great video thanks. It's something very common for JS developers I believe.

Great stuff! Can you maybe give an example of how to handle an error in myExecuteFunc?

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

Excellent but why do you type so fast as if some tiger is running behind you?

lovely

Higher order function 🚀

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

Yup this pattern is good when used sparsely. I made the mistake before of using this everywhere and things quickly spiral out of control.

Where do I find your dotfiles?

Very cool topic. I want to boost my vim like yours, could you tell what plugins you use?

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?

Muscles go hard!

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() }}

This is an adapter pattern. Decorator pattern its more about returning entity with the same type, but with additional behaviour.

the keyboard stroks sound is distracting bro, never seen a tutorial like that. can you please consider this in the fututre?

love u anthony

Has anyone taken this course? How is it so far?

Instead of passing writers and readers everywhere it would make more sense to pass a context

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 😅

Plzz include k8s deployment as well in the course 😅

we also need Anthony's muscle pattern

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.

He still calls his ex func... That's sad

I think its better to call this the handler pattern

Dude, give me your course for free if you're interested 😄

$$$

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

Love your stuff ... BUT stop moving the cursor around when not needed ... it drives me NUTS!!! I cant' watch it