► 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!
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.
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.
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.
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.*
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.
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.
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...
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
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.
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.
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 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
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 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.
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?
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?
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'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)
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.
How can a developer that don't know what is a DI Container say that golang has the best mechanic for DI? It's like saying a ship is the best way to travel around the world when you don't know what an airplane is.
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.
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.
"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 RUclipsr 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 RUclips selling shitty courses
► 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!
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.
man anthony has the rare skill of making overly complicated buzzwords into real world concepts easy to understand
programming really becomes an art for when you reach concepts like these
You got it. ❤
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.
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
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.*
It's very good you are teaching it. It's very sad anyone has to tell such basics things :)
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.
With this code example the DI principle become much more cleaner for me. Thank you, for your work!
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.
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
I just love the way how you explained Di and automatic resolve the dependency ❤❤
Im a simple man. My soul is free.
I like your channel,I am middle android developer(kotlin)and me interesting golang backend
Very nice video! But you explained more about polymorphism then DI itself =]
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?
my favorite design pattern
I've been trying to understand DI for a while now, thanks!
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
Awesome video on DIP, thanks for keeping our minds fresh with good design ♥
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.
Just a crazy concept u explained so well damn !! u r genius !!
This. Is. Lit.
Thank you so much!
So easy to understand for a topic which has been made so complicated!
great video. Will watch it twice.
Like first, watch second
I very like all your videos. Clean and to-the-point with example.
great video as always. DI was something that I've been having trouble with while using Go
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
10/10
I has been knowing this concept as "abstraction"
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 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
hey anthony you are amazing! keep making such cool videos!
I'd not call this "Dependency Injection", but a case of "Dependency Inversion" that is more inlined with how go works.
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.”
Amazing content Anthony! I learnt a lot of it! That's exactly what I looked for! Greetings from Brazil bro! :D
What is the best way to pass dependencies to the "ice placer" (like the db, api, data)?
Nice explanation with example 🫡🫡
Brilliant
You sound like George St. Pierre. Great content
Im to old for the UFC, time to clap some cheeks on RUclips
great video.
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.
Great video. Thank you for this.
ps. volume was super quiet.
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?
thanks this was really helpful
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?
Very helpful thanks. Pls zoom in. Hard to follow on small screens
Awesome ♥
well in OOP you would inject the dependency and just call the method on whatever is passed in.
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.
+ duck typing interface, there are no limits
it's so useful
Maybe a video on using DI frameworks like fx.
Kindly increase the volume of your mic.
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)
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?
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.
What theme do you use in this video?
Did you back again to vsCode, Great video BTW
Vscode is for visual purposes. Thunderclient and all that jazz
Did you make any video about how go routines are managed by go runtime?
Is there any solution to auto-wire dependencies?
is that the strategy design pattern?
great vid btw!
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.
Where we can get code for understanding purpose thanks for this kind of videos
why isnt safetyplacer a pointer in the newRockClimber method ?
How can a developer that don't know what is a DI Container say that golang has the best mechanic for DI?
It's like saying a ship is the best way to travel around the world when you don't know what an airplane is.
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.
Interesting, but your audio volume is too low compared to MacOS volume change sounds.
How do you test this at the unit and integration level.
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.
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
Sorry, I am biased and racist, so hitting the like button before playing it. 😍
Don't know if is more dangerous go down in this rabbit hole or go up and climb sandy rocks.
why don't you stick to a single editor, some days back mentioned using nvim and now i see you are using vscode.
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 RUclipsr 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 RUclips selling shitty courses
Hey @anthonygg_ nice and simple video thanks