Spring (and other DI frameworks) can inject dependencies into private fields. It looks like people like to use this because it combines some compelling properties:

• Very little boilerplate code. All you need is a simple annotation on the field.
• Since the field is private nobody outside the class can change it.

But now when you want to test your class and want to assign e.g. a mock to the field you have to either setup a Spring context in your tests or use reflection in order to access the field (just as Spring does).

Now something is really starting to smell bad here. One of the purposes of Dependency Injection is to decouple code, which in turn should make the code easier to test. Now that didn’t work out to well.

So how can we clean up this mess? We can write a setter for the field. That solves the testing problem. It adds a little boiler plate code, but hey we are talking Java here, so you should be used to that. But now we have a setter which anybody can call at any time. At the very best that doesn’t make any sense at all in the production environment. In the worst case somebody actually uses it and creates some ugly bug.

So what do you do when you don’t want anybody to change a field? Correct you make it final. Great, now you have a compile time error in the setter.You can only set a final field in a constructor. This leads naturally to the solution of all our problems (and possibly to world peace): Make your dependency a constructor argument!

This is the only place where dependencies really belong. If you try to stick to that rule I’d expect you’ll encounter the following two problems.

1. You’ll find classes with lots and lots of constructor arguments. I’ll bet that class does a lot of different things and really needs to get broken down into smaller pieces.
2. You’ll find cases where a class A needs an instance of B and B needs an instance of  A. This is a typical case of a circular dependency and is obviously bad. In my experience the solution is either to make B a part of A when the two are so strongly dependent that they really should be one class. More often though there is at least one more class C hiding in there so that B doesn’t need A but only C.

So really the problems you’ll find when doing constructor based dependency injection are problems that are present in your current code already. So don’t shoot the messenger, but fix the problems in your code and go for constructor arguments for dependency injection.

Anyway the logical next question is: How do you break circular dependencies? I find it a little disturbing that few developers can answer this question. So I’ll try to fix that.

Imagine two classes(2), forming a dependency circle. A depends on B and B depends on A. How do you break that circle, without changing the functionality? To be more precise: we are talking about the compile/deploy time dependency. At runtime the two classes need each others, so there actually will be a circular dependency.

Got it? It’s actually not that difficult: Extract all functionality of B into an interface C. Let A depend on C, B implements C and still depends on A. Circle broken.

Actually there is a piece missing. As said, at runtime we do need the circular dependency. At runtime A needs to reference an actual B. So you need a third class D which knows A and B and plugs the B into the A (using the C shaped hole).

Problem solved.

Actually this has a well known name: Dependency Injection. It should be quite easily doable without any framework in your main language.

Note(1): Larger circles are worse than smaller ones. Circles between classes of a single package are kind of ok. Circles between packages are pretty ugly. Circles between Jars are a no go and actually will break many tool chains.

Note(2): If you prefer you can replace the term ‘class’ with package or jar. In that sense a package implements another one, when it implements interfaces in that package.

Fireworks

In a couple of days I’ll start working on a new project. Actually it is an project that I worked one or two years ago. I think I did decent job last time. But there is always lots of room for improvement. So today I want to list a couple of things I want to do bettern than the last time.

More Tests – When working on that project I was the only person with real experience in automated testing. I am proud that we had a test suite and that this test suite still exists and put to good use and actually grew during the last months. Yet I consider the coverage of the tests not sufficient by far. So for every code I write, I will add an extensive set of test. I’ll also add tests for existing code, when refactoring.

Earlier Tests – One reason we didn’t produce as many tests as I would wish today is that we didn’t do TDD. It probably was a correct decission the last time, since it would have been just to much. But this time I will practice TDD as good as I can.

Cleaner Code – One of the first tests I wrote back then was a test to ensure that we don’t have circular dependencies. We succeeded in this, but still parts of the system a pretty tangled. We gonna improve that. Appart from the knowledge I took from Clean Code I’ll plan to use the toxicity metric as an important tool for that.

Dependency Injection – We considered using Spring and decided against it, because we already had about 20 libraries we hardly knew in the project. Again at that time it was a reasonable decision. But in the meantime I learned what we could have gained by using Spring. I’ll propose using it, but even when the team declines again, I’ll be able to use the concept in order to improve the code base.

So these are the things I want to improve on in the next project. What are the things you want to improve on in your next project?