► 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

man anthony has the rare skill of making overly complicated buzzwords into real world concepts easy to understand

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.

@TehKarmalizer

4 ай бұрын

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!

I very like all your videos. Clean and to-the-point with example.

Awesome video on DIP, thanks for keeping our minds fresh with good design ♥

programming really becomes an art for when you reach concepts like these

@anthonygg_

4 ай бұрын

You got it. ❤

This. Is. Lit. Thank you so much! So easy to understand for a topic which has been made so complicated!

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 ❤❤

@anthonygg_

Жыл бұрын

Im a simple man. My soul is free.

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

hey anthony you are amazing! keep making such cool videos!

Just a crazy concept u explained so well damn !! u r genius !!

great video. Will watch it twice.

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.

@anthonygg_

23 күн бұрын

Amazing comment. Thank you for that.

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.

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.

I like your channel,I am middle android developer(kotlin)and me interesting golang backend

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

@antoniocs8873

Жыл бұрын

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.

@vitiok78

Жыл бұрын

@@antoniocs8873 Golang does support reflection but it is slow. Code generation is the better approach.

@tandemwarhead

Жыл бұрын

Idk, using Uber dig/fx daily, it has some drawbacks but runtime performance is fine

This is exactly why i love go. The way things are constructed and and depend on interfaces (behaviour) instead of strong implementations

@RokoKovac

7 ай бұрын

As opposed to what? Which language doesn't allow abstractions?

thanks this was really helpful

great video.

Awesome ♥

It's very good you are teaching it. It's very sad anyone has to tell such basics things :)

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.*

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...

@TheYeti

10 ай бұрын

who are you

Nice explanation with example 🫡🫡

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.

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

my favorite design pattern

Very nice video! But you explained more about polymorphism then DI itself =]

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

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?

it's so useful

Brilliant

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 :)

@wadecodez

8 ай бұрын

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.

Did you make any video about how go routines are managed by go runtime?

Like first, watch second

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'd not call this "Dependency Injection", but a case of "Dependency Inversion" that is more inlined with how go works.

Great video. Thank you for this. ps. volume was super quiet.

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.

@novak8431

Жыл бұрын

I liked to use "do" module from samber with generics feature

@vikingthedude

7 ай бұрын

Why do people want auto-instantiating? I like doing it myself even if there are hundreds of lines of instantiation code. its explicit

@schroedingerundkatze

6 ай бұрын

​@@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.

What is the best way to pass dependencies to the "ice placer" (like the db, api, data)?

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'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?

What theme do you use in this video?

Very helpful thanks. Pls zoom in. Hard to follow on small screens

How do you test this at the unit and integration level.

Where we can get code for understanding purpose thanks for this kind of videos

Maybe a video on using DI frameworks like fx.

is that the strategy design pattern? great vid btw!

Is there any solution to auto-wire dependencies?

why isnt safetyplacer a pointer in the newRockClimber method ?

Did you back again to vsCode, Great video BTW

@anthonygg_

Жыл бұрын

Vscode is for visual purposes. Thunderclient and all that jazz

well in OOP you would inject the dependency and just call the method on whatever is passed in.

Kindly increase the volume of your mic.

+ duck typing interface, there are no limits

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)

You sound like George St. Pierre. Great content

@anthonygg_

11 ай бұрын

Im to old for the UFC, time to clap some cheeks on KZread

How do you scroll up down what is the keyboard shortcut?

@stefano_schmidt

Жыл бұрын

it's Vim extension for vsCode

@WeekendStudy-xo6lq

Жыл бұрын

@@stefano_schmidt which key both scrolls down and leaves the cursor at center

@stefano_schmidt

Жыл бұрын

@@WeekendStudy-xo6lq I don't know, I don't use Vim. Ask chatGpt or google

Interesting, but your audio volume is too low compared to MacOS volume change sounds.

Hi, please make the code screen more zoomed, difficult watch more than 5 min from mobile.

@akhil_sai

Жыл бұрын

Half of the VS code screen is left blank.

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 dependency injection. This is just the Strategy Pattern which leverages Polymorphism. I've been doing this for 20 years in Java.

@airkami

Ай бұрын

Is DI more than pattern strategy?

@obimadu6201

5 күн бұрын

Make way for the new, lol

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.

How is dependency injection different from dependency inversion?

@anthonygg_

Жыл бұрын

Im not smart enough to understand the concept of dependency inversion 😓

@eeevans

24 күн бұрын

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.

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.

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!?!?!?!!!!

This gentleman teaching in an highlander accent... is incoherent to my American ears

Adopt me!

@anthonygg_

Жыл бұрын

😂

What a bad example!

@anthonygg_

2 ай бұрын

Explain why Timmy.

@Amir-zi1hj

2 ай бұрын

@@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

@stefano_schmidt

Жыл бұрын

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

@theuniverse2268

Жыл бұрын

@@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 KZreadr 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 KZread selling shitty courses

Hey @anthonygg_ nice and simple video thanks