6 ms·
Thank you for this. I'd even say that dependency injection frameworks eliminate the most important thing of dependency injection: explicit dependencies.
by etamponi 4y ago
Thank you for this. I'd even say that dependency injection frameworks eliminate the most important thing of dependency injection: explicit dependencies.
- EdwardDiego 4y agoBut they're not though? class Foo(@Inject x: SomeType) Is still a class you can't instantiate without a correct instance of the given type. (If you're talking about field injection, then I agree, that is the devil and must be purged with fire. Constructor injection or none.) And when there's multiple instances of a given type available, a good framework refuses to guess. And I really like compile time DI for surfacing these errors far quicker than the traditional runtime approaches.
- mrkeen 4y agoMy problem is that 100% of the time, the chain of construction is as brittle as if you'd not used DI as all. It's not that clear with Foo(SomeType). What I usually deal with is: AuthController(AuthService(UserService(UserRepo(Hikari(Postgres(..))))). Now I just want to test that AuthService accepts/rejects a user based on whether they're in the system or not. I want to do something like: users = new Map<UserId, User>() auth = new AuthService(users::get) > And when there's multiple instances of a given type... (There should always be (in the case that you're writing a test for something)) > a good framework refuses to guess I do too! I want to manually wire the classes inside main() in the usual case, and manually wire (different combinations) of classes in the tests.