What's sad about Java is that the whole type-safety, compile-time-checks, minimal-runtime-surprises etc has gone out of the window since the DI craze, so now we have a platform that is as "unsafe" as Python et al, whilst still being relatively heavy to set up etc.. I guess there's still the advantage of having extensive libraries..
How does dependency injection throw type safety out the window? You can only inject types that are a subtype of the declared type. Overridden methods can't extend the types of checked exceptions that are thrown [1]. I fail to see the hole in the type system here.
I'm not a Java programmer, but I use dependency injection all the time in other language, including dynamic languages like Ruby. I find it very helpful for isolating bits of code and making extendable interfaces. I'm genuinely curious if there's a major weakness lurking in DI that I haven't discovered yet. Please help me remove my blinders.
Yeah, it's not a big risk to production, but it just makes the development loop that much more frustrating. There's nothing more annoying than building, deploying, starting, before discovering that you mispelt a bean name...
Ah! I see where my confusion lies. As others have commented, it sounds like you're talking about using a tool that does dependency injection for you; perhaps something configured in XML. I see how a tool like that would subvert a compiler's type checker.
My mental model for dependency injection is a little different. I think of dependency injection as a technique instead of a tool. The only tool I used to do DI is a text editor.
Here's an example of how I would use dependency injection (manually) in Java:
interface Dependency {
void doSomething();
}
class Foo {
Foo(Dependency x) { ... }
}
new Foo(new ConcreteDependencyA());
new Foo(new ConcreteDependencyB());
Both instances of Foo receive their dependencies at runtime, but the compiler is going to check that (1) the concrete dependencies are subtypes of the abstract dependency, (2) the concrete dependencies don't throw extra checked exceptions in their doSomething() method, and (3) the dependent class (Foo) only uses the interface of the abstract dependency. I gain the advantages of dependency injection without undermining the language's type safety.
I don't think this can be called DI, because you're not injecting them, you're passing them to the constructor. The problem with this model is that you're polluting your constructors with non-functional arguments (for example the logging provider), and that if you want to change one of these, you have to change all your constructor calls!
> because you're not injecting them, you're passing them to the constructor
Injection simply means that the dependency is sent from outside the class. That's exactly what's happening in the constructor example.
> The problem with this model is that you're polluting your constructors with non-functional arguments
I don't consider it "pollution." Who says that IDependency is non-functional? I don't think I've ever injected a non-functional dependency.
> if you want to change one of these, you have to change all your constructor calls!
This is a red herring. If you have to change all your calls, you failed to make your code DRY. That's the programmer's fault. Use a factory or default arguments.
95% of the time, the reason for injecting a dependency is that you want to use a fake implementation in your unit tests, but a particular concrete example in your production code. Have the default constructor setup the concrete dependency and use the extra constructor for your unit tests. This works most of the time for me.
interface IDependency {
void doSomething();
}
class Foo {
Foo(IDependency) { ... } // for unit tests
Foo() { this(new ConcreteDependency()); } // for production
}
Doing DI manually requires a little bit of skill, but not much. I actually find that it teaches design principles more than it requires apriori knowledge of them. Having never used a configuration-based DI tool, it wouldn't be fair for me to conclude with any comparison between the approaches. However, given that this conversation started when you complained that DI tools subvert a static type system, I'm inclined to believe that the DI tools introduce accidental complexities that outweigh their benefits in the simplest use cases.
> I don't think I've ever injected a non-functional dependency
Logging is the classic example. Or the data service provider, or CXF-type stuff
> Use a factory or default arguments
I think that's the main point. Framework-managed DI puts a stop to the factory madness that you always ended up with back in the old Java or C++ world.
> Have the default constructor setup the concrete dependency and use the extra constructor for your unit tests
This will work for a while, but when you start needing to test complex flows, you're going to end up having classes calling classes calling classes, having multiple constructors will become unmanageable.
> DI tools introduce accidental complexities that outweigh their benefits in the simplest use cases
I totally, fully, definitely agree with you! The heavy tools such as Spring or EE6 are ugly, frustrating behemoths with absolutely no advantages for small or even medium developments. But as soon as it starts becoming a 40MY+ project I find you can't avoid them :(
