1

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?

  • 3
    Have you asked them why they "roll their own"? – David Arno Jul 22 '16 at 10:45
  • 5
    Never underestimate the benefits of simplicity. Both Spring and Guice (especially Spring) are large, complex systems requiring a lot of investment in time to learn how to use them effectively. If their own DIY solution is simple and does the job, then you really need to first question whether the time required to learn eg Spring would bring sufficient benefits. Just because you view them as "best-in-show OSS projects" doesn't mean they are the best solution in all cases. They may be useful; they may not ... – David Arno Jul 22 '16 at 11:06
  • 1
    ... First try to convince yourself that they already have the best solution. If you fail to do that, then there's benefits to introducing them to Spring and/or Guice. – David Arno Jul 22 '16 at 11:07
  • 2
    FWIW all my projects start with "poor man's" DI because it's simple and small. Only later, when I decide that a framework/lib is worth the overhead and complexity, do I introduce Ninject into my projects. – RubberDuck Jul 22 '16 at 12:03
  • 3
    It depends on the company culture. Some companies refuse to use anything other than the most mainstream technologies. DI frameworks are surprisingly easy to write so why wouldn't you use your own if you didn't need the additional cruft of a better known solution? – Robbie Dee Jul 22 '16 at 13:22
5

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.

1

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.