► 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!
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.*
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.
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.
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
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.
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.
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.
Tbf, there's a lot of people who are self taught. I already did all the things in this video instinctively, but had no idea what people meant by the phrase "dependency injection"
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.
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.
Coming from .NET and C#, what the dependency injection container does there on top of just tying implementations to interfaces, is it also handles the lifecycle of objects - meaning are they Singleton, Scoped, or Transcent - meaning it's one object for the entire app, new object is created per request, or new object is created per-creation of the class.
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.
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...
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
HI ! Why don't you explain in detail the "constructor" (newRockClimber) and why I should instantiate it only with sp? From my perspective, this is the most important part to fully understand dependency injection.
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 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.
That's not the strategy pattern. The strategy, as the name suggests, will perform a logic/strategy based on the implementation received via the interface. Think of it as a switch case where each case would be an implementation of that interface. DI is simply injecting an implementation that meets the expected interface. Just like the video is showing. It's very useful in testing and makes the code flexible since you no longer depend on that specific implementation, which might not even exist yet. But you sure know how it should behave whatever implementation you come up with, it must have the same methods defined in the interface. Sometimes, DI gets called inversion control principle, or IoC, which has been stated in the comments as well. To me, they are not the same. In short, you no longer create the object/implementation manually in the code where it supposed to be created, instead, you delegate it to the framework. Thus, the object lifecycle control has been inversed : you were explicitly creating it before, now the framework is doing it for you. The key point which makes people consider DI and IoC the same i think is, IoC is heavily relying on DI. Just like the strategy pattern which is using DI as well. But, when you think about it, they all serve different purposes. I know it can get easily confusing, epecially without examples 😅. For those confused, i can only encourage you checking out the net, there are plenty of examples on different frameworks (just like this video)
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?
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)
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.
in general I agree with the sentiment, but regarding "there's no need to make it more complex than that", some google, uber and facebook engineers might disagree
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.
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.
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.
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.
"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!
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
programming really becomes an art for when you reach concepts like these
You got it. ❤
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.*
With this code example the DI principle become much more cleaner for me. Thank you, for your work!
I've been trying to understand DI for a while now, thanks!
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.
I just love the way how you explained Di and automatic resolve the dependency ❤❤
Im a simple man. My soul is free.
Just a crazy concept u explained so well damn !! u r genius !!
great video as always. DI was something that I've been having trouble with while using Go
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.
I like your channel,I am middle android developer(kotlin)and me interesting golang backend
This. Is. Lit.
Thank you so much!
So easy to understand for a topic which has been made so complicated!
my favorite design pattern
Awesome video on DIP, thanks for keeping our minds fresh with good design ♥
Amazing content Anthony! I learnt a lot of it! That's exactly what I looked for! Greetings from Brazil bro! :D
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
great video. Will watch it twice.
hey anthony you are amazing! keep making such cool videos!
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
Like first, watch second
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?
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.
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.
It's very good you are teaching it. It's very sad anyone has to tell such basics things :)
Tbf, there's a lot of people who are self taught. I already did all the things in this video instinctively, but had no idea what people meant by the phrase "dependency injection"
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.
Nice explanation with example 🫡🫡
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.
Very nice video! But you explained more about polymorphism then DI itself =]
Coming from .NET and C#, what the dependency injection container does there on top of just tying implementations to interfaces, is it also handles the lifecycle of objects - meaning are they Singleton, Scoped, or Transcent - meaning it's one object for the entire app, new object is created per request, or new object is created per-creation of the class.
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
What is the best way to pass dependencies to the "ice placer" (like the db, api, data)?
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 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
You sound like George St. Pierre. Great content
Im to old for the UFC, time to clap some cheeks on RUclips
HI ! Why don't you explain in detail the "constructor" (newRockClimber) and why I should instantiate it only with sp? From my perspective, this is the most important part to fully understand dependency injection.
You won me when you ran the thing so I could get some dopamine going 🤣
thanks this was really helpful
I has been knowing this concept as "abstraction"
What theme do you use in this video?
Great video. Thank you for this.
ps. volume was super quiet.
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.”
Awesome ♥
great video.
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.
That's not the strategy pattern.
The strategy, as the name suggests, will perform a logic/strategy based on the implementation received via the interface.
Think of it as a switch case where each case would be an implementation of that interface.
DI is simply injecting an implementation that meets the expected interface. Just like the video is showing.
It's very useful in testing and makes the code flexible since you no longer depend on that specific implementation, which might not even exist yet. But you sure know how it should behave whatever implementation you come up with, it must have the same methods defined in the interface.
Sometimes, DI gets called inversion control principle, or IoC, which has been stated in the comments as well.
To me, they are not the same.
In short, you no longer create the object/implementation manually in the code where it supposed to be created, instead, you delegate it to the framework.
Thus, the object lifecycle control has been inversed : you were explicitly creating it before, now the framework is doing it for you.
The key point which makes people consider DI and IoC the same i think is,
IoC is heavily relying on DI. Just like the strategy pattern which is using DI as well.
But, when you think about it, they all serve different purposes.
I know it can get easily confusing, epecially without examples 😅.
For those confused, i can only encourage you checking out the net, there are plenty of examples on different frameworks (just like this video)
Is there any solution to auto-wire dependencies?
Did you back again to vsCode, Great video BTW
Vscode is for visual purposes. Thunderclient and all that jazz
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?
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)
Very helpful thanks. Pls zoom in. Hard to follow on small screens
is that the strategy design pattern?
great vid btw!
why isnt safetyplacer a pointer in the newRockClimber method ?
I'd not call this "Dependency Injection", but a case of "Dependency Inversion" that is more inlined with how go works.
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?
Where we can get code for understanding purpose thanks for this kind of videos
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?
Maybe a video on using DI frameworks like fx.
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
Brilliant
+ duck typing interface, there are no limits
How do you test this at the unit and integration level.
I kinda get it, but I don't understand how I can apply this when writing my own programs. It is very hard for me to grasp design...
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.
in general I agree with the sentiment, but regarding "there's no need to make it more complex than that", some google, uber and facebook engineers might disagree
Kindly increase the volume of your mic.
it's so useful
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.
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.
well in OOP you would inject the dependency and just call the method on whatever is passed in.
Interesting, but your audio volume is too low compared to MacOS volume change sounds.
10/10
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.
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.
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.
why don't you stick to a single editor, some days back mentioned using nvim and now i see you are using vscode.
Java programmer's be like: it's NOT REAL DEPENDENCY INJECTION WHERE IS XML FILE DESCRIBING DEPENDENCIES!?!?!?!!!!
You are looking for "autowiring"? Mabe you ment: "extremely bad design just because you can't setup a package properly"
Don't know if is more dangerous go down in this rabbit hole or go up and climb sandy rocks.
Adopt me!
😂
SaftyPlacer 🤣
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!
This gentleman teaching in an highlander accent... is incoherent to my American ears
still don't understand 🤞
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