Instead of constructor injection, you really should have used an injection framework for this. Preferably one that uses an xml config file so that I would have to read and understand THAT also.
In this case you want a ThreeProvider and you don't care at all how it is implemented or where the value comes from.
It's good that the dependency on the ThreeProvider interface is defined in the constructor, that makes it clear that there is a required collaborator and your class cannot be constructed with an invalid state. If your injection framework is any good it can use this constructor to do the wiring. For example in Java Spring the only thing you need to do is add @Autowired to this constructor.
And on a side note: Spring does not require any XML for DI configuration since at least 10 years ago.
The last time I had to work on Java (more than ten years ago) it was easier to load the app into the debugger than to understand the source code.
That's f'd up.
@Configuration
public class ThreeConfiguration {
@Bean @Profile("dev")
public ThreeProvider devThree() {
return new DevThreeProvider();
}
@Bean @Profile("production")
public ThreeProvider prodThree() {
return new ProdThreeProvider();
}
}
@Component
public class Sample {
private ThreeProvider threeProvider;
@Autowired
public Sample(ThreeProvider threeProvider) {
this.threeProvider = threeProvider;
}
public int addThree(int val) {
return val + threeProvider.getThree();
}
}
2. It is derived from the desire to create not applications, but application frameworks that can handle any conceivable change request that the PO might come with. This is architecture astronaut territory. It's frustrating to work with. It's hateful to debug.
2) the ThreeProvider example is contrived indeed. In real projects this is used to provide different implementations for loggers, or sms gateways or other things that can differ between environments (prod, dev, test)
And to decouple the construction of objects from their usage. For example a rest api controller should not care how to instantiate a database connection and associated code, it should just require an implementation of a Repository interface for the model it uses.
The principle of dependency injection is a good one, but dependency injection frameworks are an unnecessary and overcomplicated way of achieving it. XML-based DI frameworks at least had a rationale - the idea was to externalise configuration, so you could change the dependencies without changing the code. It turns out this kind of externalisation isn't actually valuable in most cases (changing the dependencies is just as complicated and risky as changing code, and often needs to be coordinated with more substantive code changes, so the separation is artificial).
Once you determine that you should wire up your dependencies in code, though, there's no need for dependency injection frameworks - you can just directly write the code that wires up the dependencies.
> dependency injection frameworks are an unnecessary and overcomplicated way of achieving it.
But why? I don't want to write my own DI framework for each new project.
I'd better add one dependency, put some @Autowired (and other well-documented) annotations and continue writing business logic.
Aforementioned 'magic' is basically creating a context, scanning all annotations, registering beans, instantiating them (calling constructors), then injecting them.
Ideally, making something automated should not make it harder to do the same thing manually.
1. I launch the app
2. Spring does a bunch of stuff I only vaguely understand and can't understand from looking at the code
3. My actual code starts running
On top of that, all the spring stuff makes the memory footprint and startup time awful.
Nothing worse than breaking into the debugger and seeing a "ThingAdjectiveVerb" and you need to actually look for "ThingAdjective" and look at the "VerbFoo" entry under it.
But that's the thing. Look at the code in the comment I replied to. It calculates 6. You would have to _read_ the code to know why. A DI framework would make this situation even worse.
The unit tests for the specific implementation should catch this.
You have to read the code anyway when you are debugging this issue. And by having the implementation behind and interface you can fix the bug once and be sure that it is fixed everywhere it is used.
No, the whole point is to prove an abstraction around dependency management. All abstractions leak and for any non-trivial application you _will_ run into a scenario which forced you to learn how your abstraction works. Black magic stinks.