Opportunity cost of DIY DI?

Question

Java here. I have always used Spring DI (for Spring projects) or Guice (for non-Spring projects) for dependency injection, and have always loved them.

I recently took a job where they do 100% "DIY DI". That is, every project's main/driver class has an init() method that creates all of their objects/factories for them:

public class SomeApp {
    private DatabaseService databaseService;

    public static void main(String[] args) {
        SomeApp someApp = new SomeApp();
        someApp.run();
    }

    private void run() {
        init();

        // Now do some stuff (whatever SomeApp does).
    }

    private void init() {
        SomeAppConfig someAppConfig = readFromFileSystemSomehow();

        databaseService = new DatabaseServiceImpl(someAppConfig.getDatabaseInfo())
        // ...etc.
    }
}

I feel like there is nothing necessarily wrong with this DIY DI, however I feel like Guice and Spring DI exist for a reason, implement DI best practices, and handle a variety of situations better than what any homegrown solution could handle.

I would like to try and propose using Guice/Spring DI to this team, but before I do I want to either:

• Make sure that I have solid/concrete reasons for why these open source projects exist and do DI better than a DIY solution; or
• Perhaps amend my outlook on DIY DI if it is in fact perfectly fine and these other libs (Guice/Spring DI/Weld/etc.) aren't really necessary for proper DI practices

So I ask: What is lost by forgoing on Guice/Spring DI/etc. and using a DIY DI solution? What is the opportunity cost?

Answer 1

There are two legitimate reasons to DIY that I can think of:

1. It simplifies your life. A custom solution can fit your needs exactly whereas trying to incorporate a 3rd party approach can sometimes be more work than it's worth.
2. Eliminating/Avoiding dependencies. I really think developers in general don't put enough weight into this. There are costs to dependencies that aren't always initially obvious. When you tightly couple your application to these dependencies, the potential costs are much higher.

It seems unlikely that 1 applies here but 2 might. DI in Java got rolling before there were standards around it with Spring leading the pack and Guice close behind it. You might think now that you'll never (never ever) want to change out from Spring but you can't know that. Some of the most costly projects I've been involved in were about extracting dependencies on proprietary dependencies. I've seen companies go through the pain of building out a J2EE solution because of the portability it provides and then use proprietary features of the container and completely defeat the purpose.

This doesn't mean you shouldn't go with it, but these are the issues I would want you to address if you were to come to me with a proposal to introduce dependencies. Also be very wary of the advice of companies that clearly benefit from you being dependent on their products. They have every incentive to get you hopelessly trapped in their web of products and will often downplay or dismiss the risks associated with coupling your project to their proprietary solutions.

One a side-note, Bob Lee is really sharp and I think he had all the right intentions when he created Guice.

Answer 2

While there are lot of reasons to use Spring (I've never worked with guice so can't comment on it) they aren't always important for any given project, and it's therefore a good idea IMO to at least consider DIY DI for each new project. That said, I end up with more Spring projects than those without. My most common reasons for using Spring are:

• declarative transaction demarcation. This saves me a whole bunch of boilerplate code in places where I don't usually want it.
• scoped dependencies (e.g. in a web app having per-session or per-request objects that are created on demand) and inter-scope references that work (without needing to mess around with writing my own proxy classes)
• spring mvc makes for much tidiet projects than my usual alternative of servlets redirecting to jsp files.