5 ms·
And that was 10 years ago. We've come a long long way since then. Nowadays it would look something like this @Configuration public class ThreeConfigura
by vbsteven 8y ago
And that was 10 years ago. We've come a long long way since then. Nowadays it would look something like this
@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();
}
}
And that's about it. The Sample class does not need to worry where it ThreeProvider comes from. And the configuration about all the different implementations and in which cases they will be used are bundled together in one class.
- TickleSteve 8y ago...and the whole (non-java) software world cringes while the Java guys look puzzled wondering whats wrong with it.
- vbsteven 8y agoCan you explain why this is so cringeworthy to non-java devs?
- JustSomeNobody 8y ago1. There's Magic. 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.
- vbsteven 8y ago1) where is the magic in the aforementioned code? 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.
- culturedsystems 8y agoThe magic is in all the code that interprets those annotations. So you have to understand a large and complex framework to understand which objects are being injected (in Spring, for example, you have to keep in mind the rules about which beans are instantiated and then which of the instantiated beans are chosen for injection into a particular class), and to understand what actually gets injected (is it actually the object returned from the annotated method, or some proxy or chain of proxies adding additional behaviour to those objects?). 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.
- kovrik 8y agoCan't see where this 'magic' comes from. IoC frameworks are not rocket science. Everything is very-well documented and pretty straightforward. > 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.
- ummonk 8y agoAnd here I thought your comment about how far we have come was sarcastic...