I've been relearning java spring/springboot at the moment and realized I severely lacked depth. I find your channel very informative and clear compared to others but I still get confused how things work. Putting down here in points my understanding from the video: 1. Spring/Spring is the framework that has IoC container and use DI to manage dependencies. 2. If there are class A with dependency of class B, the framework will initialize class A and class B at the same time, ignoring the dependencies and then only supplies the dependency via DI at runtime?
Yeah, I think you've got it. If you ask Spring for an object, it can give it to you. But if that thing has dependencies, you need to give Spring a hint on how to fullfill that dependency. That's what the injection is all about. Giving Spring a hint about what dependency to provide or 'inject' when someone asks for an object. Spring can give you a video game console. But if you ask Spring to play a game on that console, it won't know what game to play. You've got to give it a hint on what game to inject into that game console. That's dependency injection!
when a class is passed into a constructor what exactly happens internally? does it make an instance of the class? when we pass the class are we passing the class itself or an object of the class ( since java is pass by copy i think object is passed) however in terms of initialization which constructor is passed and is it passed at all and will the values be initialized in the class itself or when it is passed as an object to the other class? also in practice it would all be the same as saying Potato potato = new Potato() inside another class and then we use the constructor that class has for initialization and we done right?
Nope! And it's actually a bad practice to do so. I'll explain both. Check out line 9 at 19:40. You'll see the Spring Context is created by passing the Game class to the constructor. The line is highlighted. That removes the need for any Spring @Component annotations on the class. An XML file or Configuration file achieves the same result. The @Component annotation you think of is a bit of an anti-pattern. The purpose of DI is to have an external container manage your beans WITHOUT imposing on them. The container knows about your beans, but your beans should never know about the container. It's not loosely coupled if you tightly couple your JavaBeans to a giant framework like Spring. So, when you put a @Component annotation on a bean, you've linked it to Spring. You now have a Spring element that permanently ties that bean to Spring! For small projects, or times when you're never, ever going to leave Spring, then it doesn't matter. And the latter is probably true for most projects. But philosophically, filling POJOs with elements that tie them to Spring, or any framework, runs counter to the concept of isolation and loose coupling.
from 20:00 onward: *this* is exactly what i was stating yesterday for more than 2 hours but you didn't seem to grasp this very basic comment at all. I literally had written: "any time you pass an object the class is dependent on and does not create it you are passing a dependency!" whereupon you claimed: "Again, you keep asserting that any time you pass an argument to a constructor it is injection. That demonstrates a complete and total misunderstanding of what DI is." You don't know what you are teaching, lol! Your game class is DEPENDENT on score; but does not create score itself. Thus, the dependency is injected from outside. This is done either through constructor, or in the case of java spring annotation. But what spring does for you when you retrieve a DI-container managed class instance is literally nothing but get all annotated fields per reflection, look into its DI-container whether an instance of Score exists and assigns the value it has to the annotated field .. again .. per reflection. Yet, if you did not use the spring-framework, and you would create Score in the main class alongside Game and passed the instance of Score to the Game via constructor, you literally would inject a dependency. But in this case, the spring framework does this for you. Why did you argue with me over this simple observation? Dont you know how DI-container work internally? Emberassing!
Because you are outright wrong. Again, simply passing an object to a setter or constructor, or for that matter, directly initializing a variable is NOT dependency injection. It's simply passing a parameter. That's not DI, and that's not IoC. If that were the case, every line of code would be DI, and every class ever created would be an IoC container. Simply not a sustainable position. The actual DEFINITION of DI is that the objects whose dependencies are injected come from an IoC container. So your suggestion that simply calling a constructor without any regard to the objects being loaded from a framework is simply hogwash. Go look at Martin Fowlers discussion of the origin of the term DI. It was defined to describe the process of transparently setting the properties of references for objects that are pulled from an IoC container. The IoC container is a requirement. Again, they didn't invent the term DI to simply describe the basic act of calling a method or a constructor. If that's what you think it is, then you simply fail to understand dependency injection.
@@cameronmcnz that is *your* formal definition of dependency injection you are presupposing to be correct in order to prove your point which is circular reasoning. The terms inversion of control and dependency injection only *describe* a set of patterns and principles but do *not prescribe* the actual implementation. The basic concept of dependency injection is indeed about supplying dependencies from outside the object. HOW do supply the dependency is another topic. But IN A WAY creating an instance of a client and passing instances of services to that client during instanciation is dependency injection.
@@stati5tik That is *not* my formal definition. That is the definition of the term given by the people who invented the term. Again, your assertion is that any time a parameter is passed to a method, a parameter is passed to a constructor, or a variable is assigned a value then it's DI. That's absolutely insane. Industry leaders didn't invent the term DI to describe initializing a variable. Go read Martin Fowler's article on the topic where he describes why the term was coined and how it is defined. You'll see that nowhere does he indicate that the industry was struggling for a term to describe 'initializing an instance variable' as you seem to believe DI is all about. Simply initializing a variable outside the class in which it is declared *is not* dependency injection. That's just basic object-oriented programming. If you don't understand that, then you simply don't understand dependency injection.
@@cameronmcnz mate, it is not about just passing parameters and you know very well what I am trying to state. It is about passing dependencies. The moment you pass an object (a service for example) to a class (a client for example) which does not create the service but depends on it you are basically injecting a dependency. This is dependency injection in its very core idea. You know that, but I think you just took this a bit too personal. I have written several DI containers in c#, either for my physics simulations or blazor projects. The very core idea is that services are dependencies which lifetime is managed by my own DI container and are injected to other services or clients when required (i.e. as a constructor argument); *this* is what DI is all about.. and i am certain you understand my point aswell.
Injecting is a term reserved for the situation where an IoC container transparently fulfills the dependencies of the resources it manages. Initializing a variable or passing an object to a method is not DI. I believe you have written code that calls a non-default constructor, and I believe you have created setters and used them. Have you created a DI container? No, because simply calling a setter method is not DI. The fact that you would tell people that any time they call a setter method then they've done DI is both incorrect and irresponsible.
THIS IS SOOOO UNDERRATED
I've been relearning java spring/springboot at the moment and realized I severely lacked depth. I find your channel very informative and clear compared to others but I still get confused how things work. Putting down here in points my understanding from the video:
1. Spring/Spring is the framework that has IoC container and use DI to manage dependencies.
2. If there are class A with dependency of class B, the framework will initialize class A and class B at the same time, ignoring the dependencies and then only supplies the dependency via DI at runtime?
Yeah, I think you've got it. If you ask Spring for an object, it can give it to you. But if that thing has dependencies, you need to give Spring a hint on how to fullfill that dependency. That's what the injection is all about. Giving Spring a hint about what dependency to provide or 'inject' when someone asks for an object. Spring can give you a video game console. But if you ask Spring to play a game on that console, it won't know what game to play. You've got to give it a hint on what game to inject into that game console. That's dependency injection!
@@cameronmcnz I see. Appreciate the response. thanks a lot! and keep doing more videos. :)
when a class is passed into a constructor what exactly happens internally? does it make an instance of the class? when we pass the class are we passing the class itself or an object of the class ( since java is pass by copy i think object is passed) however in terms of initialization which constructor is passed and is it passed at all and will the values be initialized in the class itself or when it is passed as an object to the other class? also in practice it would all be the same as saying Potato potato = new Potato() inside another class and then we use the constructor that class has for initialization and we done right?
Doesnt Game class need an annotation on it ?
Nope! And it's actually a bad practice to do so. I'll explain both.
Check out line 9 at 19:40. You'll see the Spring Context is created by passing the Game class to the constructor. The line is highlighted. That removes the need for any Spring @Component annotations on the class. An XML file or Configuration file achieves the same result. The @Component annotation you think of is a bit of an anti-pattern.
The purpose of DI is to have an external container manage your beans WITHOUT imposing on them. The container knows about your beans, but your beans should never know about the container. It's not loosely coupled if you tightly couple your JavaBeans to a giant framework like Spring.
So, when you put a @Component annotation on a bean, you've linked it to Spring. You now have a Spring element that permanently ties that bean to Spring!
For small projects, or times when you're never, ever going to leave Spring, then it doesn't matter. And the latter is probably true for most projects. But philosophically, filling POJOs with elements that tie them to Spring, or any framework, runs counter to the concept of isolation and loose coupling.
from 20:00 onward: *this* is exactly what i was stating yesterday for more than 2 hours but you didn't seem to grasp this very basic comment at all. I literally had written:
"any time you pass an object the class is dependent on and does not create it you are passing a dependency!"
whereupon you claimed:
"Again, you keep asserting that any time you pass an argument to a constructor it is injection. That demonstrates a complete and total misunderstanding of what DI is."
You don't know what you are teaching, lol!
Your game class is DEPENDENT on score; but does not create score itself. Thus, the dependency is injected from outside. This is done either through constructor, or in the case of java spring annotation.
But what spring does for you when you retrieve a DI-container managed class instance is literally nothing but get all annotated fields per reflection, look into its DI-container whether an instance of Score exists and assigns the value it has to the annotated field .. again .. per reflection.
Yet, if you did not use the spring-framework, and you would create Score in the main class alongside Game and passed the instance of Score to the Game via constructor, you literally would inject a dependency. But in this case, the spring framework does this for you.
Why did you argue with me over this simple observation? Dont you know how DI-container work internally?
Emberassing!
Because you are outright wrong. Again, simply passing an object to a setter or constructor, or for that matter, directly initializing a variable is NOT dependency injection. It's simply passing a parameter. That's not DI, and that's not IoC. If that were the case, every line of code would be DI, and every class ever created would be an IoC container. Simply not a sustainable position.
The actual DEFINITION of DI is that the objects whose dependencies are injected come from an IoC container. So your suggestion that simply calling a constructor without any regard to the objects being loaded from a framework is simply hogwash.
Go look at Martin Fowlers discussion of the origin of the term DI. It was defined to describe the process of transparently setting the properties of references for objects that are pulled from an IoC container. The IoC container is a requirement.
Again, they didn't invent the term DI to simply describe the basic act of calling a method or a constructor. If that's what you think it is, then you simply fail to understand dependency injection.
@@cameronmcnz that is *your* formal definition of dependency injection you are presupposing to be correct in order to prove your point which is circular reasoning. The terms inversion of control and dependency injection only *describe* a set of patterns and principles but do *not prescribe* the actual implementation. The basic concept of dependency injection is indeed about supplying dependencies from outside the object. HOW do supply the dependency is another topic. But IN A WAY creating an instance of a client and passing instances of services to that client during instanciation is dependency injection.
@@stati5tik That is *not* my formal definition. That is the definition of the term given by the people who invented the term.
Again, your assertion is that any time a parameter is passed to a method, a parameter is passed to a constructor, or a variable is assigned a value then it's DI. That's absolutely insane. Industry leaders didn't invent the term DI to describe initializing a variable.
Go read Martin Fowler's article on the topic where he describes why the term was coined and how it is defined. You'll see that nowhere does he indicate that the industry was struggling for a term to describe 'initializing an instance variable' as you seem to believe DI is all about.
Simply initializing a variable outside the class in which it is declared *is not* dependency injection. That's just basic object-oriented programming. If you don't understand that, then you simply don't understand dependency injection.
@@cameronmcnz mate, it is not about just passing parameters and you know very well what I am trying to state. It is about passing dependencies. The moment you pass an object (a service for example) to a class (a client for example) which does not create the service but depends on it you are basically injecting a dependency. This is dependency injection in its very core idea. You know that, but I think you just took this a bit too personal. I have written several DI containers in c#, either for my physics simulations or blazor projects. The very core idea is that services are dependencies which lifetime is managed by my own DI container and are injected to other services or clients when required (i.e. as a constructor argument); *this* is what DI is all about.. and i am certain you understand my point aswell.
Injecting is a term reserved for the situation where an IoC container transparently fulfills the dependencies of the resources it manages.
Initializing a variable or passing an object to a method is not DI.
I believe you have written code that calls a non-default constructor, and I believe you have created setters and used them.
Have you created a DI container? No, because simply calling a setter method is not DI.
The fact that you would tell people that any time they call a setter method then they've done DI is both incorrect and irresponsible.