4 ms·

A reason to like it is that in a system with DI and IoC you spend less time trying to build up objects and pass them to where they need to go, since it's simple

A reason to like it is that in a system with DI and IoC you spend less time trying to build up objects and pass them to where they need to go, since it's simple to just inject them into the class you want using an annotation. Spring takes care of the object creation under the hood for you. A reason not to like IoC is that since it's so easy to use it can lead to sloppiness since you're not thinking about the overall structure of the application as much.

makmanalp 9y ago
This explanation always messes with me... Why are you trying to build up objects and pass them into places? (er, sorry, I don't mean you of course, I just mean in general) When / why is that ever a thing that someone needs to do so often that it becomes a concern? How come I rarely if ever see this in the e.g. python or C++ world? I get the idea of decoupling component implementations from their host objects but I just can't see most use cases needing that level of generality. Especially when it comes at the price of smearing a big and complicated IoC framework all over your code. Past a threshold of codebase size and complexity, I see the value of course, but IoC frameworks get pitched too often as a thing that everyone should be using IMHO. Even for testing we already have mocking tools that handle replacing component objects with mocked versions just fine, and we don't need IoC tools for that.
- _xgw 9y ago
  > Why are you trying to build up objects and pass them into places? Well, that place needs those objects to do its job. > When / why is that ever a thing that someone needs to do so often that it becomes a concern? In web applications, at least, you find yourself with a few controllers, which all need a few services which all need a few repositories to access the database... I guess you can see where this is going. Declaring in your class' constructor that instances need an object of `Type` is the less repetitive way of saying that an instance of a class needs something. Writing the code that builds objects and passes them to your constructors would be quite repetitive.
- chris_wot 9y ago
  If you ever see someone implement the command pattern, you'll see passing objects.
- tytytytytytytyt 9y ago
  > Why are you trying to build up objects and pass them into places? Maybe something like the mediator pattern? There's definitely use cases for it, but I think a lot of the time the cure isn't any better than the disease.
usrusr 9y ago
With DI, that one big messy application root object that every codebase seems to naturally gravitate to becomes a generic, clean, reusable mechanism you did not write yourself. (Unless you put another big messy application root object on top of your DI, which I suppose is a learning experience I am not alone with)

makmanalp 9y ago

This explanation always messes with me... Why are you trying to build up objects and pass them into places? (er, sorry, I don't mean you of course, I just mean in general) When / why is that ever a thing that someone needs to do so often that it becomes a concern? How come I rarely if ever see this in the e.g. python or C++ world? I get the idea of decoupling component implementations from their host objects but I just can't see most use cases needing that level of generality. Especially when it comes at the price of smearing a big and complicated IoC framework all over your code. Past a threshold of codebase size and complexity, I see the value of course, but IoC frameworks get pitched too often as a thing that everyone should be using IMHO. Even for testing we already have mocking tools that handle replacing component objects with mocked versions just fine, and we don't need IoC tools for that.

_xgw 9y ago
> Why are you trying to build up objects and pass them into places? Well, that place needs those objects to do its job. > When / why is that ever a thing that someone needs to do so often that it becomes a concern? In web applications, at least, you find yourself with a few controllers, which all need a few services which all need a few repositories to access the database... I guess you can see where this is going. Declaring in your class' constructor that instances need an object of `Type` is the less repetitive way of saying that an instance of a class needs something. Writing the code that builds objects and passes them to your constructors would be quite repetitive.
chris_wot 9y ago
If you ever see someone implement the command pattern, you'll see passing objects.
tytytytytytytyt 9y ago
> Why are you trying to build up objects and pass them into places? Maybe something like the mediator pattern? There's definitely use cases for it, but I think a lot of the time the cure isn't any better than the disease.

usrusr 9y ago

With DI, that one big messy application root object that every codebase seems to naturally gravitate to becomes a generic, clean, reusable mechanism you did not write yourself. (Unless you put another big messy application root object on top of your DI, which I suppose is a learning experience I am not alone with)