31

I'm relatively unskilled in Dependency Injection, and I'd like to learn some best practices and anti-patterns to use and avoid respectively when using DI.

3
  • 2
    I don't think "language-agnostic" helps here: different languages dictate radically different approaches - you really wouldn't want to do the same thing in C++ as, say Ruby. Commented Nov 5, 2009 at 19:36
  • 2
    Then it might be worthwhile to ask separate questions per language? Still, I imagine there are enough general patterns so a generic question is in order. Commented Nov 5, 2009 at 21:19
  • I'd encourage anyone interested in contributing to this question to check out the dependency injection docs topics instead. Commented Feb 8, 2017 at 0:37

6 Answers 6

8

I really enjoyed this article regarding DI, as it's targeted towards people who don't have a ton of DI experience, or don't even know what it is.

https://web.archive.org/web/20230531024338/https://mtaulty.com/2009/08/10/m_11554/

What’s Unity?

It’s a “dependency injection container”. 

Now, at that point a bunch of folks reading this will say “Yes, we know and we’re already using it for reasons A, B, C or we’ve elected not to use it for reasons X,Y,Z ” and I imagine a bunch of other folks might say;

“Huh? What’s a dependency injection container?” 

This post is for the latter people – it’s not meant to be exhaustive but hopefully it’s not completely unhelpful either :-)

Sign up to request clarification or add additional context in comments.

Comments

3

In my opinion, Dhanji Prasanna's book Dependency Injection is a must read for software designers, both beginners and experts. It deals directly with your DI questions.

1 Comment

3

There's a best practices section in Guice's user's guide.

Comments

1

I've found that when I see a violation of the Law of Demeter that is a hint that I might want dependency injection.

For example:

void doit() { i += object.anotherobject.addvalue; //violation of Law of Demeter } 

Sometimes hints that I might want to dependency inject anotherobject.

1 Comment

This makes some sense, though is a bit of a leap, and is incomplete. If you find a violation of the law of demeter, you find an opportunity to choose to abstract. Any time you abstract, you have an opportunity to choose to inject the dependency rather than create it yourself. So this is an indicator, but only just. There are potentially more opportunities to abstract than just this, and it might be useful to avoid DI in places where it costs more to implement than you could possibly get out of it. Still, +1 though.
0

My basic rule about when to use DI is that I will inject between layers, so between my controller and the dao would be a layer, so I can inject, so that if I want to mock out a layer I can.

I think using DI within the same layer is not a good idea mainly because the layer should be tightly coupled, as they are related, unless you have a user story that makes it useful.

For example, if your DAO is may be on separate computers then you may need to be able to pretend that they are one layer, but use DI to actually switch between all on one machine and separate machines. Then the developer can do everything on one machine and it should work on separate machines.

But, unless there is some pressing need, I think DI within the same layer is an unnecessary complication.

2 Comments

Well using dependency injection within a layer you will re-use existing component instances, conserving resources. Also I would say you are fostering good programming habits by forcing a modular design.
I just see it getting more complicated than it needs to be, but that depends on what is on the layer. I tend to just do it between layers, but that is why I explained why doing it between a layer can be helpful, just not something I will suggest.
0

Here's a dependency injection anti-pattern: Multiple Constructors.

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.