When you realize everything ur team has been doing is wrong....

Not even using Spring, DI correctly...

Fuck...

How do you screw up DI that badly?! The usual worst case I see is someone making literally *everything* a bean, or using field rather than constructor injection. Both are reasonably east to fix.

@AlmondSauce oh it's the latter. How to fix?

Actually, if you define a Bean public Some Interface x() { return new Impl()}?

After fixing the constructor, the Impl() wouldn't compile anymore bc missing args?

@donuts Sure, but then you provide methods that return the additional beans you need, which you can then inject into the constructor of your `Impl()`.

It can take a while and be a bit of a long slog, but it's not *hard* per-se.

The only point it gets a bit hairy is if you have a mixture of injected and non-injected fields that you want in a single constructor, in which case you'd need to do some refactoring to separate out what should be the spring-managed and non-spring-managed parts.

@AlmondSauce hm, so then you get a very big Configuration class declaring all the mini beans which then inject into complex beans?

Also a lot of apps seen to have multiple Configuration classes. How do you split it out refuses it. For example one bean creates the MongoConnection. But another one needs to use it.

There's an @Import, but I think you would need to write @AutoWired MongoConnection connection, to use it?

@donuts Sorry, missed this - yeah, you get a big config class which isn't ideal, but it's far better than what you'd have otherwise and you can always refactor it down to manageable config classes at a later date. At least by that point you can sanely unit test and mock, which is the main concern.

The norm is to minimise the coupling between those config classes however, so you wouldn't need to share beans between them. Sometimes that's tricky however, and it's easiest just to leave it as one big class even if it looks a tad messy.