Object Mentor Blog: Dependency Injection Inversion

Dependency Injection Inversion

Uncle Bob — Sun, 17 Jan 2010 12:42:00 -0600

Dependency Injection is all the rage. There are several frameworks that will help you inject dependencies into your system. Some use XML (God help us) to specify those dependencies. Others use simple statements in code. In either case, the goal of these frameworks is to help you create instances without having to resort to new or Factories.

I think these frameworks are great tools. But I also think you should carefully restrict how and where you use them.

Consider, for example, this simple example using Google’s Guice framework.


 public class BillingApplication {
   public static void main(String[] args) {
    Injector injector = Guice.createInjector(new BillingModule());
    BillingService billingService = injector.getInstance(BillingService.class);
    billingService.processCharge(2034, "Bob");
  }
 }

My goal is to create an instance of BillingService. To do this, I first get an Injector from Guice. Then I use the injector to get an instance of my BillingService class. What’s so great about this? Well, take a look at the constructor of the BillingService class.


class BillingService {
  private CreditCardProcessor processor;
  private TransactionLog transactionLog;

  @Inject
  BillingService(CreditCardProcessor processor, TransactionLog transactionLog) {
    this.processor = processor;
    this.transactionLog = transactionLog;
  }

  public void processCharge(int amount, String id) {
    boolean approval = processor.approve(amount, id);
    transactionLog.log(
      String.format("Transaction by %s for %d %s",
      id, amount, approvalCode(approval)));
  }

  private String approvalCode(boolean approval) {
    return approval?"approved":"denied";
  }
}

Oh ho! The BillingService constructor requires two arguments! A CreditCardProcessor and a TransactionLog. How was the main program able to create an instance of BillingService without those two arguments? That’s the magic of Guice (and of all Dependency Injection frameworks). Guice knows that the BillingService needs those two arguments, and it knows how to create them. Did you see that funky @Inject attribute above the constructor? That’s how it got connected into Guice.

And here’s the magic module that tells Guice how to create the arguments for the BillingService


public class BillingModule extends AbstractModule {
  protected void configure() {
    bind(TransactionLog.class).to(DatabaseTransactionLog.class);
    bind(CreditCardProcessor.class).to(MyCreditCardProcessor.class);
  }
}

Clever these Google-folk! The two bind functions tell Guice that whenever we need an instance of a TransactionLog it should use an instance of DatabaseTransactionLog. Whenever it needs a CreditCardProcessor it should use an instance of MyCreditCardProcessor.

Isn’t that cool! Now you don’t have to build factories. You don’t have to use new. You just tell Guice how to map interfaces to implementations, and which constructors to inject those implementations in to, and then call Injector.getInstance(SomeClass.class); and voila! You have your instance automatically constructed for you. Cool.

Well, yes it’s cool. On the other hand, consider this code:


public class BillingApplicationNoGuice {
  public static void main(String[] args) {
    CreditCardProcessor cp = new MyCreditCardProcessor();
    TransactionLog tl = new DatabaseTransactionLog();
    BillingService bs = new BillingService(cp, tl);
    bs.processCharge(9000, "Bob");
  }
}

Why is this worse? It seems to me it’s better.

But Uncle Bob, you’ve violated DIP by creating concrete instances!

True, but you have to mention concrete instances somewhere. main seems like a perfectly good place for that. Indeed, it seems better than hiding the concrete references in BillingModule.

I don’t want a bunch of secret modules with bind calls scattered all around my code. I don’t want to have to hunt for the particular bind call for the Zapple interface when I’m looking at some module. I want to know where all the instances are created.

But Uncle Bob, You’d know where they are because this is a Guice application.

I don’t want to write a Guice application. Guice is a framework, and I don’t want framework code smeared all through my application. I want to keep frameworks nicely decoupled and at arms-length from the main body of my code. I don’t want to have @Inject attributes everywhere and bind calls hidden under rocks.

But Uncle Bob, What if I want to get an instance of BillingService from deep in the bowels of my application? With Guice I can just say injector.getInstance(BillingService.class);.

True, but I don’t want to have createInstance calls scattered all through my code. I don’t want Guice to be poured all over my app. I want my app to be clean, not soaked in Guice.

But Uncle Bob, That means I have to use new or factories, or pass globals around.

You think the injector is not a global? You think BillingService.class is not a global? There will always be globals to deal with. You can’t write systems without them. You just need to manage them nicely.

And, no, I don’t have to use new everywhere, and I don’t need factories. I can do something as simple as:


public class BillingApplicationNoGuice {
  public static void main(String[] args) {
    CreditCardProcessor cp = new MyCreditCardProcessor();
    TransactionLog tl = new DatabaseTransactionLog();
    BillingService.instance = new BillingService(cp, tl);

    // Deep in the bowels of my system.
    BillingService.instance.processCharge(9000, "Bob");
  }
}

But Uncle Bob, what if you want to create many instances of BillingService rather than just that one singleton?

Then I’d use a factory, like so:


public class BillingApplication {
   public static void main(String[] args) {
    Injector injector = Guice.createInjector(new BillingModule());
    BillingService.factory = new BillingServiceFactory(injector);

    // Deep in the bowels of my code.
    BillingService billingService = BillingService.factory.make();
    billingService.processCharge(2034, "Bob");
  }
}

But Uncle Bob, I thought the whole idea was to avoid factories!

Hardly. After all, Guice is just a big factory. But you didn’t let me finish. Did you notice that I passed the Guice injector into the factory? Here’s the factory implementation.


public class BillingServiceFactory extends AbstractModule {
  private Injector injector;

  public BillingServiceFactory(Injector injector) {
    this.injector = injector;
  }

  protected void configure() {
    bind(TransactionLog.class).to(DatabaseTransactionLog.class);
    bind(CreditCardProcessor.class).to(MyCreditCardProcessor.class);
  }

  public BillingService make() {
    return injector.getInstance(BillingService.class);
  }
}

I like this because now all the Guice is in one well understood place. I don’t have Guice all over my application. Rather, I’ve got factories that contain the Guice. Guicey factories that keep the Guice from being smeared all through my application.

What’s more, if I wanted to replace Guice with some other DI framework, I know exactly what classes would need to change, and how to change them. So I’ve kept Guice uncoupled from my application.

Indeed, using this form allows me to defer using Guice until I think it’s necessary. I can just build the factories the good old GOF way until the need to externalize dependencies emerges.

But Uncle Bob, don’t you think Dependency Injection is a good thing?

Of course I do. Dependency Injection is just a special case of Dependency Inversion. I think Dependency Inversion is so important that I want to invert the dependencies on Guice! I don’t want lots of concrete Guice dependencies scattered through my code.

BTW, did you notice that I was using Dependency Injection even when I wasn’t using Guice at all? This is nice and simple manual dependency injection. Here’s that code again in case you don’t want to look back:



public class BillingApplicationNoGuice {
  public static void main(String[] args) {
    CreditCardProcessor cp = new MyCreditCardProcessor();
    TransactionLog tl = new DatabaseTransactionLog();
    BillingService bs = new BillingService(cp, tl);
    bs.processCharge(9000, "Bob");
  }
}

Dependency Injection doesn’t require a framework; it just requires that you invert your dependencies and then construct and pass your arguments to deeper layers. Consider, for example, that the following test works just fine in all the cases above. It does not rely on Guice, it only relies on the fact that dependencies were inverted and can be injected into BillingService



public class BillingServiceTest {
  private LogSpy log;

  @Before
  public void setup() {
    log = new LogSpy();
  }

  @Test
  public void approval() throws Exception {
    BillingService bs = new BillingService(new Approver(), log);
    bs.processCharge(9000, "Bob");
    assertEquals("Transaction by Bob for 9000 approved", log.getLogged());
  }

  @Test
  public void denial() throws Exception {
    BillingService bs = new BillingService(new Denier(), log);
    bs.processCharge(9000, "Bob");
    assertEquals("Transaction by Bob for 9000 denied", log.getLogged());    
  }
}

class Approver implements CreditCardProcessor {
  public boolean approve(int amount, String id) {
    return true;
  }
}

class Denier implements CreditCardProcessor {
  public boolean approve(int amount, String id) {
    return false;
  }
}

class LogSpy implements TransactionLog {
  private String logged;

  public void log(String s) {
    logged = s;
  }

  public String getLogged() {
    return logged;
  }
}

Also notice that I rolled my own Test Doubles (we used to call them mocks, but we’re not allowed to anymore.) It would have been tragic to use a mocking framework for such a simple set of tests.

Most of the time the best kind of Dependency Injection to use, is the manual kind. Externalized dependency injection of the kind that Guice provides is appropriate for those classes that you know will be extension points for your system.

But for classes that aren’t obvious extension points, you will simply know the concrete type you need, and can create it at a relatively high level and inject it down as an interface to the lower levels. If, one day, you find that you need to externalize that dependency, it’ll be easy because you’ve already inverted and injected it.

"Dependency Injection Inversion" by trampolines for sale

Tue, 07 Feb 2012 20:38:37 -0600

I just got home from a gathering and I thought that I’d surf the web for some time before I’d hit the sack. As I saw your posting, I was quite interested to find out more and I thought I would learn about it even further. I am most generally keen on trampolines for sale but your content has also fascinated me. Thank you for posting and thanks for allowing me post here.

"Dependency Injection Inversion" by cisco training

Tue, 07 Feb 2012 19:32:11 -0600

It’s my day off from my job and I figured I’d stay at home for a change. I was just searching through a few sites that fascinate me and I came upon this blog. The Cisco training webpage that I also discovered was absolutely enjoyable. I had a blast reviewing their blog posts and reviews. Anyhow, I think that this webpage here is merely impressive. Thanks for letting me hang around on this site. I will look forward to coming back when I have yet another time off at home.

"Dependency Injection Inversion" by frasi celebri

Tue, 07 Feb 2012 13:42:13 -0600

Your articles is great, thanks

"Dependency Injection Inversion" by Get Air Conditioner

Tue, 07 Feb 2012 08:03:38 -0600

Also notice that I rolled my own Test Doubles (we used to call them mocks, but we’re not allowed to anymore.) It would have been tragic to use a mocking framework for such a simple set of tests.

"Dependency Injection Inversion" by iphone 4S jailbreak

Tue, 07 Feb 2012 06:13:40 -0600

I would really say that after the jailbreak of iPhone 4S there are many t hings that have been changed.

iphone 4S jailbreak

"Dependency Injection Inversion" by pest control reading

Tue, 07 Feb 2012 05:05:04 -0600

I love this site. This is a very good site and good post too.

"Dependency Injection Inversion" by learnh2h@gmail.com

Tue, 07 Feb 2012 02:35:52 -0600

Thanks for sharing experience.it should be really a great post. learn how to hack

"Dependency Injection Inversion" by learnh2h@gmail.com

Tue, 07 Feb 2012 01:57:21 -0600

Thanks for sharing experience.it should be really a great post.

learn how to hack

"Dependency Injection Inversion" by vitra furniture

Mon, 06 Feb 2012 19:35:31 -0600

I’m not really normally inspired by informative material, but your topic honestly made me give thought to your viewpoints. You have absolutely presented beneficial and sound thoughts that are logical and exciting. I privately care to talk about vitra furniture. Therefore I am conscious of the effort it will require to create an educational post like this. Thank you so much for featuring your positive work.

"Dependency Injection Inversion" by nice

Sun, 05 Feb 2012 12:37:44 -0600

nice

"Dependency Injection Inversion" by carbon monoxide detector

Fri, 03 Feb 2012 01:21:08 -0600

I recently read some articles that were so dull and off center that I couldn’t abide finishing them. Your article is not one of those articles. I like your content.

"Dependency Injection Inversion" by Andrew Reynolds

Thu, 02 Feb 2012 01:53:54 -0600

I am not normally stimulated by informative material, though

your post truly made me gives some thought to your viewpoints.

You have unquestionably offered important and reliable

thoughts that are logical and appealing. I privately love to

comment on Andrew Reynolds. So I know the hard work it

requires to make an informative article like this. Thanks a

lot for spreading your fine work.

"Dependency Injection Inversion" by half hitch

Wed, 01 Feb 2012 21:35:25 -0600

Just after discovering half hitch review, I chanced on your site. I didn’t assume that a plain site that it would seem would produce much fascinating and impressive content. Keep undertaking an excellent task. I’m guaranteed a lot of people would rely on you!

"Dependency Injection Inversion" by Ady Blink

Tue, 31 Jan 2012 03:07:07 -0600

thanks, nice artikle

"Dependency Injection Inversion" by motor vehicle dealer

Mon, 30 Jan 2012 04:50:15 -0600

I do not know what to say. This web page is awesome. That not really a really big review, but its all I could come up with after examining this. You know so much about this subject. So much so that you developed me want to find it. Your web page website is my stepping-stone, my companion. Thanks for the mind up on this subject.

"Dependency Injection Inversion" by Administrative Medical Assistant classes Southern California

Mon, 30 Jan 2012 04:48:46 -0600

These are some awesome details to use. We use this at operate all-time. Keep up the truly awesome. Thanks for all this. I like your operate..

"Dependency Injection Inversion" by Pass

Sat, 28 Jan 2012 09:15:09 -0600

very good information. this code is realy for professionals.

"Dependency Injection Inversion" by Pass

Sat, 28 Jan 2012 09:12:07 -0600

Nice post. I have idea.

"Dependency Injection Inversion" by Anglu kalbos kursai Vilniuje

Mon, 23 Jan 2012 10:43:03 -0600

Nice post. Interesting, informative. Keep going. It would be greate to read more on this topic!

"Dependency Injection Inversion" by www.mokslosodas.lt

Mon, 23 Jan 2012 10:42:30 -0600

Nice post. Interesting, informative. Keep going. It would be greate to read more on this topic!

"Dependency Injection Inversion" by wholesale dealers license

Mon, 23 Jan 2012 03:52:44 -0600

very nice to see your blog here i like it and would like to appreciate you on this so keep it up man for more details

"Dependency Injection Inversion" by free cell phone spy

Mon, 23 Jan 2012 01:47:16 -0600

Thanks for the awesome article here. I am a huge fan of design so it is really interesting for me to read such stuff. I just hope to see more such nice articles.!

"Dependency Injection Inversion" by tramadol

Sun, 22 Jan 2012 03:27:49 -0600

great post i would like you to guess post on my site http://www.tramadol.usaonline.biz

"Dependency Injection Inversion" by AP English literature

Thu, 19 Jan 2012 05:55:08 -0600

Really very good information web page. I have to admit that we’re definitely warm the idea

"Dependency Injection Inversion" by quotes about life and love

Tue, 17 Jan 2012 10:45:44 -0600

XML is so terrible I can’t believe anyone would use it.