Yes, in a way. If you pass instances to that that class another class manages the instanciation of that particular class and by that the lifetime of that object. The dependency is therefore injected. And God alone knows best.
Yes, and that would be 100% incorrect. They didn't invent the term DI to describe passing arguments to a constructor. We were doing that 20 years before the term DI was invented. The presenter seems to actually have no idea what DI is.
@@stati5tik No, not in any way. Do you really think they invented the term DI to describe passing arguments to a method? No. No they didn't. This video describes how to use a parameterized constructor, something you learn after coding Hello World. But this has nothing to do with dependency injection.
@@cameronmcnz yes, it is - in a way - dependency injection. It seems as if u dont know what the basic principle of that is: inversion of control. When you have a class A that is dependent on references passed through constructor, the very class I that instanciates A acts as a DI container managing the lifetime of the said object's which references it passes further to A. The basic principle is: if A does not create all the object's it needs the dependency must be injected externally.
@@stati5tik What's with this 'in a way' vagueness? Either it is or it isn't, and calling a parameterized constructor most definitely is not. Do you actually think the term DI was invented to describe calling a parameterized constructor or passing a value into a setter? Because if you do, then you have no idea what DI is, which seems rather clear from the video. You're suggesting that every time one class calls the constructor of another class that it's DI, and that simply is not the case. It demonstrates a fundamental misunderstanding of both DI and IoC.
People make playlists with 20+ vids and still can't explain why we use it in the 1st place. And you explained it so precisely in just 2 min. Fuckin legend.
Those videos are so good, people underappreciate how good for problem solving a solution is when hard problems get a simple high level insight, especially if you also give them illustrations. Well done!
This boy has the gift of explaining, I had already understood what dependency injection is, but with just 2 minutes, everyone can understand this concept. THANKS👍
Hey man can you make a video on how to properly read the android documentation? There are very few videos on youtube and how to do so and most of the aren't really helpful at all! Here is an idea: Just show how YOU read the documentation and what you do if you dont understand any topics.
Hi Phillip. Thanks alot for this short and very explanatory video. I found dependency injection quite confusing but after watching this I have a good idea what it means and why it is useful. Thanks again Sensei 😊
Philipp I have been following on Instagram and I must say I admire the fact that you keep the android community updated! I would love to see you present a sample project containing the latest architecture of android in 2021
Yes well 2 minutes explaining what it is, and a couple 30 min videos describing a couple of premade solutions but what about a full course on it? Dependency management is one of the most difficult aspects of large scale enterprise level application development and doing DI correctly is far from easy...the concept of how is simple at the core but understanding when and what, then keeping it manageable and teatable across dozens of modules can be a huge undertaking. I would love to see a video about dependency injection the conceptual and theoretical rather than a specific tool
Honestly I’m more confused now, how is providing arguments to a class constructor function all there is to DI? If it’s as simple as function parameters, why on Earth is DI even needed as a concept, when it’s so basic to programming? By that definition, a function f(x) has DI when you provide x, since you can think of f as a class with one method and one class property
You are 100% correct. What is described here is not DI. The presenter doesn't understand the concept. Calling a non-default constructor is not dependency injection, and anyone who says it is fails to understand the concept.
"Giving an object its instance variables", I wish I had seen this nice and simple explanation earlier, before I had to go through all the overworded definitions online that confused the sh*t out of me
Just so you know, giving an object instance variables is NOT dependency injection. The leaders of the industry didn't invent the term DI to describe a basic feature of every programming language that people learn after writing their first hello world. If initializing a variable is DI, then every setter you've ever called is DI, and every class you wrote that did so is an IoC container. Does that sound like a logical conclusion to you, or does such a ludicrous and unbounded conclusion not prove that the definition provided is fundamentally wrong?
@cameronmcnz I've seen you say this a bunch in these comments now. Yet you never explain what you the DI actually is. And do I think that programmers would invent a overly complicated word for an old and simple concept that people have been doing forever? Yes of course I do.
@@Zipperheaddttl You really think that leaders of the industry wasted their time just to come up with a new term to describe something as basic as 'calling a setter' or 'calling a non-default constructor.' Or do you think they were trying to describe an arising new pattern that didn't have a name yet? Seriously, just apply Occam's razor. The term doesn't describe calling a setter! The term's origin and what it describes is all explained in Martin Folwer's blog describing the specific situation in which an object retrieved by an IoC container has properties unobtrusively initialized by the framework. It's a pattern that provided loose coupling in a manner that contrasts against a service locator, which is exactly what Fowler does in his blog explaining it. The problem is that junior programmers don't understand terms like 'service locator' or 'IoC' and think "oh, he must mean calling a constructor!" If you go and read his article, you will see that never in the article does Fowler ever suggest that DI is simply calling a setter method or initializing a variable outside of a class. To suggest such a thing demonstrates a complete and total lack of understanding of IoC, DI and basic, fundamental OOA&D programming concepts.
@@Zipperheaddttl Just use some common sense. Do you think leaders of the industry got together and struggled to come up with a new term to describe 'initializing a variable' or 'calling a setter?' Or does it make more sense that the term was invented to describe a new and emerging development pattern that didn't have a proper name? Martin Fowler, who invented the term, was a signer of the Agile Manifesto for goodness sakes. He's not sitting around thinking 'we need a new term to describe variable initialization!' If you read Martin Fowlers blog about the word's origin and the word's meaning, you will see the term describes the *specific* pattern in which an object retrieved from an IoC container has its property unobstrusively initialzed by the underlying framework. A pattern that stood in stark contrast at the time to the service locator pattern. Here's the problem. Novice programers don't understand advanced terms like DI or IoC or 'Service Locator' and so they put out videos saying "oh, DI is just calling a setter! It's just calling a non-default constructor!" Pardon? How could anyone read Martin Fowler's blog and conclude DI is simply initializing an instance variable outside of a class? Initializing an object outside a class is a basic part of OOA/D. OOA/D wouldn't exist without it. It's something you learn right after 'Hello World'. Trust me, parameterizing a constructor is not DI. Anyone who suggests it is simply doesn't understand the concept.
@@Zipperheaddttl The term was coined by Martin Fowler to describe the new and novel way IoC containers were resolving the dependencies of the objects they managed without imposing on the business logic the same way a service locator would. That's what Di is. Problem is, to understand it, people need to understand ideas like IoC, containers and the service locator problem. Since those topics are beyond the junior developers who record these videos, they just say "DI is calling a setter!" I assure you, calling a setter or a non-default constructor is not DI. That's a basic programming concept that predates the term DI by 20 years.
This is like having a pointer to another class.. in the Computer class.. first we initialize the pointer with null values in the private field section And then in our public constructor we assign what ever value for that object the computer gets from outside computer class
Bro you talk about Managing memory in Dependency Injection.. Do we need to manage the memory (lifetime of that dependency objects we are using)? Because if we use java or kotlin do we need to still explicitly deallocate memory for unused object? if so how can we do that?
This video made it worse for me, your definition is like "if you need something to be specific for each object that consumes it, then go ahead and make instance for each object". Which is the equivalent of "if you feel hungry, then go eat", or "just don't be stupid". The fact that this....."Strategy" even has a name, is very confusing to me.
Another video that thinks passing arguments to a constructor is dependency injection. What you described is the textbook definition of a constructor and why you parameterize one. But if you think DI is simply calling a parameterized constructor, then you don't know what DI is. I'd even go so far as to say teaching people that is somewhat irresponsible. They didn't invent the term DI to describe a basic programming concept like passing arguments to a method. 🤦♂
Great video! Simple and easy to understand. I have a video suggestion: Could you show us how to prepopulate a room database with the .createFromAsset or .createFromFile methods? It would be greatly appreciated! Grüße aus Deutschland!
So anytime I've made a class with a constructor that takes arguments I've just done dependency injection? That's essentially what I got from this.
Yes, in a way. If you pass instances to that that class another class manages the instanciation of that particular class and by that the lifetime of that object. The dependency is therefore injected.
And God alone knows best.
Yes, and that would be 100% incorrect. They didn't invent the term DI to describe passing arguments to a constructor. We were doing that 20 years before the term DI was invented. The presenter seems to actually have no idea what DI is.
@@stati5tik No, not in any way. Do you really think they invented the term DI to describe passing arguments to a method? No. No they didn't. This video describes how to use a parameterized constructor, something you learn after coding Hello World. But this has nothing to do with dependency injection.
@@cameronmcnz yes, it is - in a way - dependency injection. It seems as if u dont know what the basic principle of that is: inversion of control. When you have a class A that is dependent on references passed through constructor, the very class I that instanciates A acts as a DI container managing the lifetime of the said object's which references it passes further to A.
The basic principle is: if A does not create all the object's it needs the dependency must be injected externally.
@@stati5tik What's with this 'in a way' vagueness? Either it is or it isn't, and calling a parameterized constructor most definitely is not. Do you actually think the term DI was invented to describe calling a parameterized constructor or passing a value into a setter? Because if you do, then you have no idea what DI is, which seems rather clear from the video. You're suggesting that every time one class calls the constructor of another class that it's DI, and that simply is not the case. It demonstrates a fundamental misunderstanding of both DI and IoC.
People make playlists with 20+ vids and still can't explain why we use it in the 1st place. And you explained it so precisely in just 2 min. Fuckin legend.
Thanks a lot!
I feel attacked :'(
Java programmers discover function arguments
Thank you sir finally I can understand the dependency injection
Coding in flow, glad to see you are learning something new too!:)
ha ha ha 🤣🤣🤣
Oh geeez
Can’t stop laughing on this comment here! 🤣🤣
Lmaooo🤣
Those videos are so good, people underappreciate how good for problem solving a solution is when hard problems get a simple high level insight, especially if you also give them illustrations. Well done!
This boy has the gift of explaining, I had already understood what dependency injection is, but with just 2 minutes, everyone can understand this concept. THANKS👍
Thank you sir...Today after 1.5 years in Android I was able to understand dependency injection. I feared from this word.
you're welcome
That's a such a good video to start understanding the concept. Congrats!
Dear lord! Just perfect work with this video!
i recommend applying this to one of your projects, to witness the hellscape you've become immersed in
Please make tutorial for hit multiple api with different model using retrofit and coroutine 🙏🏻
Wow. This is a great video with the simplest explanation. Thank you so much for this.
You're awesome man, great content!
Just the reminder i needed. Thank you
Hey man can you make a video on how to properly read the android documentation? There are very few videos on youtube and how to do so and most of the aren't really helpful at all! Here is an idea: Just show how YOU read the documentation and what you do if you dont understand any topics.
have you found any good one?
Thank You ! You just earned a new subscriber 😇
Hi Phillip. Thanks alot for this short and very explanatory video. I found dependency injection quite confusing but after watching this I have a good idea what it means and why it is useful. Thanks again Sensei 😊
Philipp I have been following on Instagram and I must say I admire the fact that you keep the android community updated! I would love to see you present a sample project containing the latest architecture of android in 2021
Thanks! The latest architecture is still MVVM and I have a lot about that :D
Yes well 2 minutes explaining what it is, and a couple 30 min videos describing a couple of premade solutions but what about a full course on it?
Dependency management is one of the most difficult aspects of large scale enterprise level application development and doing DI correctly is far from easy...the concept of how is simple at the core but understanding when and what, then keeping it manageable and teatable across dozens of modules can be a huge undertaking.
I would love to see a video about dependency injection the conceptual and theoretical rather than a specific tool
dont understand who will do that @0:58 ?
too good explanation ❤❤
This was easy peasy here. Thanks
Honestly I’m more confused now, how is providing arguments to a class constructor function all there is to DI? If it’s as simple as function parameters, why on Earth is DI even needed as a concept, when it’s so basic to programming? By that definition, a function f(x) has DI when you provide x, since you can think of f as a class with one method and one class property
Yep it's all about managing your dependencies and not initializing them all over the place
You are 100% correct. What is described here is not DI. The presenter doesn't understand the concept. Calling a non-default constructor is not dependency injection, and anyone who says it is fails to understand the concept.
"Giving an object its instance variables", I wish I had seen this nice and simple explanation earlier, before I had to go through all the overworded definitions online that confused the sh*t out of me
Just so you know, giving an object instance variables is NOT dependency injection. The leaders of the industry didn't invent the term DI to describe a basic feature of every programming language that people learn after writing their first hello world. If initializing a variable is DI, then every setter you've ever called is DI, and every class you wrote that did so is an IoC container. Does that sound like a logical conclusion to you, or does such a ludicrous and unbounded conclusion not prove that the definition provided is fundamentally wrong?
@cameronmcnz I've seen you say this a bunch in these comments now. Yet you never explain what you the DI actually is.
And do I think that programmers would invent a overly complicated word for an old and simple concept that people have been doing forever? Yes of course I do.
@@Zipperheaddttl You really think that leaders of the industry wasted their time just to come up with a new term to describe something as basic as 'calling a setter' or 'calling a non-default constructor.' Or do you think they were trying to describe an arising new pattern that didn't have a name yet? Seriously, just apply Occam's razor. The term doesn't describe calling a setter!
The term's origin and what it describes is all explained in Martin Folwer's blog describing the specific situation in which an object retrieved by an IoC container has properties unobtrusively initialized by the framework. It's a pattern that provided loose coupling in a manner that contrasts against a service locator, which is exactly what Fowler does in his blog explaining it.
The problem is that junior programmers don't understand terms like 'service locator' or 'IoC' and think "oh, he must mean calling a constructor!" If you go and read his article, you will see that never in the article does Fowler ever suggest that DI is simply calling a setter method or initializing a variable outside of a class. To suggest such a thing demonstrates a complete and total lack of understanding of IoC, DI and basic, fundamental OOA&D programming concepts.
@@Zipperheaddttl Just use some common sense.
Do you think leaders of the industry got together and struggled to come up with a new term to describe 'initializing a variable' or 'calling a setter?' Or does it make more sense that the term was invented to describe a new and emerging development pattern that didn't have a proper name?
Martin Fowler, who invented the term, was a signer of the Agile Manifesto for goodness sakes. He's not sitting around thinking 'we need a new term to describe variable initialization!'
If you read Martin Fowlers blog about the word's origin and the word's meaning, you will see the term describes the *specific* pattern in which an object retrieved from an IoC container has its property unobstrusively initialzed by the underlying framework. A pattern that stood in stark contrast at the time to the service locator pattern.
Here's the problem. Novice programers don't understand advanced terms like DI or IoC or 'Service Locator' and so they put out videos saying "oh, DI is just calling a setter! It's just calling a non-default constructor!"
Pardon? How could anyone read Martin Fowler's blog and conclude DI is simply initializing an instance variable outside of a class? Initializing an object outside a class is a basic part of OOA/D. OOA/D wouldn't exist without it. It's something you learn right after 'Hello World'.
Trust me, parameterizing a constructor is not DI. Anyone who suggests it is simply doesn't understand the concept.
@@Zipperheaddttl The term was coined by Martin Fowler to describe the new and novel way IoC containers were resolving the dependencies of the objects they managed without imposing on the business logic the same way a service locator would.
That's what Di is. Problem is, to understand it, people need to understand ideas like IoC, containers and the service locator problem. Since those topics are beyond the junior developers who record these videos, they just say "DI is calling a setter!"
I assure you, calling a setter or a non-default constructor is not DI. That's a basic programming concept that predates the term DI by 20 years.
Simply the best. Keep up the great tutorials 👍
Thanks! 🙏
This was a great video! Thank you
The Best! As usual!
That's why I love software development. I don't speak English, but I understood what was said.
Hi Phillip, I'm becoming your fan - love the way u explain things. Thanks!!
Thanks!
Very neatly explained, Thanks Philip
Thanks! I finally understand what is dependency injection!
thaaankkss man, what a great explanation
very good quality, thanks!
Awsome explanation
This is like having a pointer to another class..
in the Computer class..
first we initialize the pointer with null values in the private field section
And then in our public constructor we assign what ever value for that object the computer gets from outside computer class
You really help beginners like me♥️
Philipp, where can I get the outro music that you used in this video?
It is so good!
i love the song very good video. Please upload a song only video as well please . Looking forward to hearing from you
I have watched alot of videos, definitely longer than this, but I failed to get them, until I came here
Always Super😀
nice explained!
Fantastic video, Pity this video was not around in 2014 when dagger thing came out
Damn I can't believe someone explained it this fast?
So is it similar to using an abstract class?
Please make tutorial on jetpack compose
background music is a bit loud
This is a perfect explanation of a complex subject that *SOME FAMOUS* engineers seem to relish in overcomplicating.... *cough*thermosiphon*cough*
Thank you!
Please create an android app using dagger.
Bro you talk about
Managing memory in Dependency Injection..
Do we need to manage the memory (lifetime of that dependency objects we are using)?
Because if we use java or kotlin do we need to still explicitly deallocate memory for unused object?
if so how can we do that?
Java has a garbage collector so it is not needed
great bruh
For the next video please put a lofi song on the background :)
Can you tell how to reset android stuido basic but i cant a good video on youtube
music is too loud
Hi Phillip, from where you are learning this topics in details?
From your mama
So "constructor injection" is just using a constructor... the way you normally do?
Yes
Thanks! :)
Does anyone know what they are saying?
nailed it.
This video made it worse for me, your definition is like "if you need something to be specific for each object that consumes it, then go ahead and make instance for each object".
Which is the equivalent of "if you feel hungry, then go eat", or "just don't be stupid".
The fact that this....."Strategy" even has a name, is very confusing to me.
Mission Passed
Respect++
you'r going to change the boring teaching method into fully dopamine release content like watching a movie
Thank you❤️
Brilliant
500th Like ❤️👋🏼
0:44 YT links block the video
Epic!
Bro this was the best explanation ever. How in the world did you think of this example?!
song name ??
very nice
Never seen beautiful explanation like this
You are truly awesome tutor
Thank you🙏🙏
that's gold
Ty
request tutorial content provider sir. Thanks you
They think they are safe now :D
Another video that thinks passing arguments to a constructor is dependency injection. What you described is the textbook definition of a constructor and why you parameterize one. But if you think DI is simply calling a parameterized constructor, then you don't know what DI is. I'd even go so far as to say teaching people that is somewhat irresponsible. They didn't invent the term DI to describe a basic programming concept like passing arguments to a method. 🤦♂
Awesome
Great video! Simple and easy to understand. I have a video suggestion: Could you show us how to prepopulate a room database with the .createFromAsset or .createFromFile methods? It would be greatly appreciated! Grüße aus Deutschland!
Nice! Could you make video about custom view and compound view. There's not much video about that on youtube. Thanks 😊
not yet. I plan on doing that when jetpack compose is out
❤❤
while(true) { println("You're my hero") }
what a weird choice of music :)
Thank you sir finally I can understand the dependency injection.