Mastering Dependency Injection In Golang
Vložit
- čas přidán 5. 08. 2024
- ► Join my Discord community for free education 👉 / discord
► Pre order (get 30% off) my exclusive Golang course 👉 fulltimegodev.com
► Follow me on Twitter 👉 / anthdm
► Follow me on GitHub 👉 github.com/anthdm
In this Golang tutorial, we'll dive into the world of dependency injection in Golang. We'll explore what dependency injection is and why it's important in modern software development. By the end of this video, you'll have a solid understanding of how to use dependency injection in your Golang projects to write more modular, maintainable, and testable code.
► Join my Discord community for free education 👉 discord.com/invite/bDy8t4b3Rz
► Pre order (get 30% off) my Golang course 👉 fulltimegodev.com
Thanks for watching
Crux of the Video: If your program depends on an implementation, that's a hardcoded dependency. But if your program depends on a behaviour, you are a GOD.. Love that !!
This video need a million likes, because I don't understand why it is so hard to explain DI, especially for beginners. This video make it look so simple and yes it is!
man anthony has the rare skill of making overly complicated buzzwords into real world concepts easy to understand
Legendary. I've been fumbling with this for a while now. Thank you for breaking it down so clearly
To everyone wondering 😅 you might be confusing dependency inversion, injection, autowiring. @AnthonyGG is showing injection (passing the SafetyPlacer to the RockClimber instead of creating it within) AND inversion (RockClimber depends on the SaftetyPlacer interface instead of the implementation).
Autowiring or auto-resolution etc on the other hand is what will automagically resolve dependency tree's and inject them and most frameworks come with a di container supporting this nowadays. Hope this helps 🎉
On a side note, by passing the number of rocks climbed to placeSafeties(climbs int), you could move the decision out of the RockClimber, since the SafetyPlacer implementation might know best after how many climbs one should be placed.
I don’t use DI frameworks, but that sounds like a managed collection of event handlers or internal services aggregated into a singleton service container available globally to an application.
With this code example the DI principle become much more cleaner for me. Thank you, for your work!
programming really becomes an art for when you reach concepts like these
You got it. ❤
Awesome video on DIP, thanks for keeping our minds fresh with good design ♥
This. Is. Lit.
Thank you so much!
So easy to understand for a topic which has been made so complicated!
great video as always. DI was something that I've been having trouble with while using Go
Amazing content Anthony! I learnt a lot of it! That's exactly what I looked for! Greetings from Brazil bro! :D
I've been trying to understand DI for a while now, thanks!
I just love the way how you explained Di and automatic resolve the dependency ❤❤
Im a simple man. My soul is free.
hey anthony you are amazing! keep making such cool videos!
I am just getting into Go. Dependency injection is simply extracting behavior into another object, following the single responsibility principle and providing that behavior as a dependency through constructor parameters.
what he is doing here is actually implementing the Dependency Inversion Principle of SOLID. With the interface and polymorphic types he depends on an abstraction instead of an implementation.
Just to explain, the DI container part is a component that contains all the dependency providers in the form of factories or singletons (that often might be even lazily initiated)...which I think is what people want, and you missed in your example. While it is true that a DI container is not technically needed for DI, when you have 200 different components with different dependencies between each other *it would be nice to reduce the boilerplate code for generating singleton and have a DI container to figure out in which order each component has to be created and initialised, without having to touch all the injection chain when you want to add a dependency in a nested component.*
Just a crazy concept u explained so well damn !! u r genius !!
great video. Will watch it twice.
I very like all your videos. Clean and to-the-point with example.
By "dependency injection container" those people mean "service container" from some frameworks in OOP.
How it works there:
You have a class that implements an interface and is doing some work. It's a service. And you have another class that wants to use this service. So... You include the interface of a first class in the constructor of a second class.
Then the framework kicks in. Upon the initialisation process framework auto initializes all the classes marked as "services" and puts initialized objects into the key-value storage named "service container". Then the framework analyzes other classes that include "services" in their constructors as dependencies and initializes them too.
So basically you don't need to bootstrap your dependencies manually. The framework is doing it for you behind the scenes
Hopefully the author will tackle this at some point. Implementing DIC in more dynamic languages is a lot simpler than in more strict ones, at least from what I've seen. Not sure how well Golang supports reflection.
@@antoniocs8873 Golang does support reflection but it is slow. Code generation is the better approach.
Idk, using Uber dig/fx daily, it has some drawbacks but runtime performance is fine
I like your channel,I am middle android developer(kotlin)and me interesting golang backend
This is exactly why i love go. The way things are constructed and and depend on interfaces (behaviour) instead of strong implementations
As opposed to what? Which language doesn't allow abstractions?
Awesome ♥
thanks this was really helpful
It's very good you are teaching it. It's very sad anyone has to tell such basics things :)
For the "Dependency injection" part you successfully explain what "Dependency" is, and then most of the time you demonstrate How to use Golang interface with different implementation.. I feel like this video is explaining the Golang interface and Polymorphism, there is not much explanation about dependency injection here.. There is much more to demonstrate about it than what you have here:
You should at least make a struct A with 2 different dependencies B, C, try to register them to a Dependency Container, use the Container to help A resolve the Depdencies B, C whenever it needed.. why the Container and Resolver will help to manage complex Golang project... and talk about the lifetime of the Dependencies...
who are you
great video.
Thank you for that video.
I think it would be even shorter w/o repetition, but hey, it is important topic to understand. Thx.
I would definitely mention that DI makes code testable for the cases where a dependency is sb else code/lib. having an interface allows to mock it easier with some mock generating libs like testify/mock.
Nice explanation with example 🫡🫡
Like first, watch second
my favorite design pattern
Nice, well done! Seems like some structs have behavior (verb) while other represent things (noun). Wondering if there's an idiom around keeping them separate? A way to communicate that intention in the code?
Dependency Inversion is requiring your dependencies be satisfied from the outside (i.e. constructor parameters, property injection, etc.) Dependency Injection is satisfying those dependency requirements in some fashion. Dependency Injection frameworks (containers) do that by satisfying those dependencies in some defined way. This is usually accomplished by registering rules on how to satisfy a dependency on a particular type (For request of ISomeInterface, create and return SomeObject). Also the lifetime of the object is implied in the way the rule is defined (transient, singleton, request, etc.). Then an object is requested of a particular type and if it has been registered with the DI framework, it will be created using that rule and by satisfying any other types depended upon by that type and so forth until all dependencies have been satisfied (dependency tree). What Anthony demonstrated was a single level of dependency inversion/dependency injection for which a DI framework would be overkill. Where a DI framework comes in handy is when you have deeply nested types where creating all the types and passing them down through all the constructors of all the types is not practical nor desired.
Amazing comment. Thank you for that.
What is the best way to pass dependencies to the "ice placer" (like the db, api, data)?
Now imagine you would not need to inject any dependencies by writing code manually, so you can guess what a DI container does for you. But if a DI container really fits into a language without classes is at least questionable. Nowadays classes are rather used to realize services (like data providers or data sinks) which themself depend on other services etc. Because nobody wants to update this whole tree every time when something changes DI containers are great. Nobody has to care when using services what dependencies they have - only declare it once. It's like with package managers. If the SQLite package depends on a SSL package and this on another one, why should one care? The package manager does his job and provide you a SQLite package that works. This is exactly what a DI container does! In addition, data classes (or data structs) are (hopefully) separated from this services. Functions to manipulate those data are often also separated from this data structs (no hard core OO any more!!!) to keep everything more simple and easy to test.
great video, I wanna mention that depending on interface instead of concrete implementation is based on dependency inversion principle which is a design pattern used with dependency injection
I'm trying to use function to implement the same functionality and it works as the following code:
package main
import "fmt"
type RockClimber struct {
rocksClimbed int
sp func()
}
func (rc *RockClimber) climbRock() {
rc.rocksClimbed++
if rc.rocksClimbed == 10 {
rc.sp()
}
}
func iceSafetyPlacer() {
fmt.Println("placing my Ice Safeties")
}
func main() {
rc := &RockClimber{sp: iceSafetyPlacer}
for i := 0; i < 11; i++ {
rc.climbRock()
}
}
Now my question is, is it a good way to do it? What are pros and cons of using function as DI?
it's so useful
Brilliant
What theme do you use in this video?
i'm sorry i cant quite understand the explanation at first,
so to summary it up
you use a abstraction and constructor to build a depency injecton?
How do you test this at the unit and integration level.
I didn't realize I was doing the exact same thing to mock functions for test purpose, like mocking repository part to only test the service part above that needs those repository calls ahah.
The tricky thing is to understand that when you declare an interface, methods will implements it automatically for you
Very nice video! But you explained more about polymorphism then DI itself =]
Did you make any video about how go routines are managed by go runtime?
why isnt safetyplacer a pointer in the newRockClimber method ?
My understanding from this video is that, in a nutshell, Dependency Injection can be done using Interfaces, where we can define multiple/different BEHAVIOURS to the same "Function/Object name". Correct me if I am wrong or elaborate more on this if possible :)
You are correct. When thinking about DI, it's best to ask yourself what is an instance and what is a specification/protocol? Instances of hard-coded dependencies like structs can only be one type. Whereas a specification does not care what the type of object is as long as it implements the required members.
DI can be done using hard-coded instances, but think about it: are you really depending on the exact type, or are you just expecting certain methods and members to be available? That's where an interface becomes useful. When it's hard-coded, you limit yourself to one type of object, but with a specification, you allow many types of objects.
When you combine interfaces and DI, you can swap out huge parts of your application with only a few lines of code. Some devs call these drivers, plugins, etc.
Is there any solution to auto-wire dependencies?
I'm not a Go developer so pardon me if mistaken, but there seems to be no link between the interface and the implementations.
Nothing seems to enforce the existence of placeSafeties() on the IceSafetyPlacer through an interface (as you'd have in C# or Java, for example)
Great video. Thank you for this.
ps. volume was super quiet.
People complaining about no dependency in go probably compare it to what they can have when they use Java/Spring. There are ways to do the same thing in go, like Google Wire.
A thing that is really important when talking about dependency injection is that it becomes very important when you mock components behavior and have to inject the mock components instead of the real ones.
I has been knowing this concept as "abstraction"
As a good reason for DI might be hard to phrase: “If you will be dependent on variations of the same base logic, it makes sense to construct that dependency as an injectable variable as you will then be able to be flexible in when to inject that then specific variation of that generic logic.”
I think what people want in GO is a DI system, not just to be able implement DI in their code. Basically, to stop worrying about instantiating custom structs and instead have a framework or library do it for them by reading function parameters or struct field types.
I liked to use "do" module from samber with generics feature
Why do people want auto-instantiating? I like doing it myself even if there are hundreds of lines of instantiation code. its explicit
@@vikingthedude Imagine you want to install a database on a Linux system and you need to install the 200 packages that it depends on, each one by one, manually in the correct order. This is what you prefer when coding. When you start to distinguish between services, data and functions (and keep them separate to handle complexity and make them testable) you will realize that there is no need to instantiate anything else then your data. Surly no functions and services are the DIs job. You only say: Give me this service and viola.
is that the strategy design pattern?
great vid btw!
I'd not call this "Dependency Injection", but a case of "Dependency Inversion" that is more inlined with how go works.
Where we can get code for understanding purpose thanks for this kind of videos
How do you scroll up down what is the keyboard shortcut?
it's Vim extension for vsCode
@@stefano_schmidt which key both scrolls down and leaves the cursor at center
@@WeekendStudy-xo6lq I don't know, I don't use Vim. Ask chatGpt or google
Very helpful thanks. Pls zoom in. Hard to follow on small screens
Did you back again to vsCode, Great video BTW
Vscode is for visual purposes. Thunderclient and all that jazz
You sound like George St. Pierre. Great content
Im to old for the UFC, time to clap some cheeks on CZcams
Hi, please make the code screen more zoomed, difficult watch more than 5 min from mobile.
Half of the VS code screen is left blank.
Kindly increase the volume of your mic.
Maybe a video on using DI frameworks like fx.
Interesting, but your audio volume is too low compared to MacOS volume change sounds.
But isn't the point of a DI framework, that any class can just demand what it wants injected and it gets it without changing any intermediate code, as long as something conforming to the demanded type (usually an interface) was injected at the dependency root?
Because your code doesn't solve that problem at all, as far as I can see.
Or maybe I'm missing something crucial here, as I'm not used to programming without a DI framework.
I mean what you're describing here should be possible in e.g. C# as well, but there are numerous DI-frameworks in C# and it's standard that people use them.
well in OOP you would inject the dependency and just call the method on whatever is passed in.
+ duck typing interface, there are no limits
How is dependency injection different from dependency inversion?
Im not smart enough to understand the concept of dependency inversion 😓
Dependency Inversion is requiring your dependencies be satisfied from the outside (i.e. constructor parameters, property injection, etc.) Dependency Injection is satisfying those dependency requirements in some fashion. Dependency Injection frameworks (containers) do that by satisfying those dependencies in some defined way. This is usually accomplished by registering rules on how to satisfy a dependency on a particular type (For request of ISomeInterface, create and return SomeObject). Also the lifetime of the object is implied in the way the rule is defined (transient, singleton, request, etc.). Then an object is requested of a particular type and if it has been registered with the DI framework, it will be created using that rule and by satisfying any other types depended upon by that type and so forth until all dependencies have been satisfied (dependency tree). What Anthony demonstrated was a single level of dependency inversion/dependency injection for which a DI framework would be overkill. Where a DI framework comes in handy is when you have deeply nested types where creating all the types and passing them down through all the constructors of all the types is not practical nor desired.
Sorry, I am biased and racist, so hitting the like button before playing it. 😍
This is NOT dependency injection. This is just the Strategy Pattern which leverages Polymorphism. I've been doing this for 20 years in Java.
Is DI more than pattern strategy?
Make way for the new, lol
It is indeed dependency injection. It is just manually injected, not using any ioc containers which is mainstream in Java and c#
I guess it is just not fully covered. Because for every dependency injection something that manages this dependency life cycle is staying, and here it wasn't covered.
I think you’re probably well aware this is not what people mean when they talk about dependency injection.
What you did isn’t even what I would consider dependency injection… that’s manual wiring.
This is not what dependency injection is about at all. With go yes using an interface the implementation is no longer a concern, but that doesn't mean that this makes it dependency injection in any way, you don't define the dependency as a singleton, transient, factory or any of the lazy loaded variants, but design it's all singleton, which is not what the topic is about, but i guess it's a good explanation on interfaces, which is needed in go, because they sort of don't work the way one would assume.
I personally don't like when people do this, because you just misinformed couple of hundred or people, that will one day be asked the question on an actual interview probably to demonstrate it, and if it's the same explanation here, good luck getting that job offer.
why don't you stick to a single editor, some days back mentioned using nvim and now i see you are using vscode.
Don't know if is more dangerous go down in this rabbit hole or go up and climb sandy rocks.
You are looking for "autowiring"? Mabe you ment: "extremely bad design just because you can't setup a package properly"
Java programmer's be like: it's NOT REAL DEPENDENCY INJECTION WHERE IS XML FILE DESCRIBING DEPENDENCIES!?!?!?!!!!
Adopt me!
😂
This gentleman teaching in an highlander accent... is incoherent to my American ears
What a bad example!
Explain why Timmy.
@@anthonygg_ this is not even considered dependency injection. This example has no problem which can be solved with dependency injection!
Don't use dep injection
"dependency injection"
in golang:
- create an interface
- create an implementation
- create a function
- construct the instance
- pass in the instance to a constructor
- variable assignment
??? where is the actual injection here? you saying a = 5? you call this injection? this is generic stuff.
in other languages dependency injection looks like this:
- implement your service
- declare your variable
you're done... golang is just over complicating trivial things.
I guess every youtuber gotta make a living... shrugs
I'm pretty sure the author has no clue what is the Dependency Injection.
Golang is pretty weird language and bad structured, but the tutorials like this always surprise me
@@stefano_schmidt he knows dependency injection pattern not actual dependency injection.
And the DI pattern itself is just shit if the language framework doesn't support adaquate tooling.
DI is never used without a framework/tooling it's always providd by that.
This guy is just a hype CZcamsr like the rest of em teaching shit and selling courses. ROFL. Real engineers are busy making money with their real engineering experience and not on CZcams selling shitty courses
Hey @anthonygg_ nice and simple video thanks