Jake Herringbone

Simpler dependency injection

In my last post, I wrote about how Java’s final modifier could be replaced with a mutable modifier, helping us to follow modern coding practices.

Another feature Java and other languages lack is a built-in understanding of dependency injection. I’ve been using Spring and Guice for a few years now, and it’s so clear to me that dependency injection is absolutely essential to writing a complex application. Even more than separating code into classes, we must avoid mixing the wiring with the logic. It makes code much more testable – if you look at the Testability explorer metric, it is partly based on the expense you incur in testing when a dependency cannot be injected – you are bound to test the object with that particular collaborator.

In Java, a typical incantation of constructor injection looks like this:

class Foo {
  private final Dependency1 d1;
  private final Dependency2 d2;
  public Foo(Dependency1 d1, Dependency2 d2) {
    this.d1 = d1;
    this.d2 = d2;
  }
}

The only information we are providing here is that to construct this class, we’ll need access to two dependencies, and we’ve given them names. This is how most classes should start, and the list of dependencies can be long. Why not treat this just like arguments to a method? We just provide the types and names of the arguments, and then they become new variables in method scope.

What we need to improve this is Properties. Just ask Java Posse co-host Joe Nuxoll – Java needs properties. If you don’t know, a property is just like a public member variable, except that you can write a set or get method for it later if you like. It replaces the silly Javabeans spec – to client code, it looks just like a public member, you just use object.property = 1 to set and object.property to get. I like how they are implemented in ActionScript, with set and get keywords to override the assignment/dereference:

public var one:int;
private var _two:int;
public function get two():int {
  return _two + 1;
}
public function set two(i:int):void {
  _two = i - 1;
}

Now we can dream up an example:

class Foo(Dependency1 d1, Dependency2 d2) {
  void doThing() {
    d1.print();
    d2 = null; // not allowed - the property is read-only
}
Foo foo = new Foo(new Dependency1(), new Dependency2());
foo.d1; // also not allowed - the properties are private

This would create private read-only properties d1 and d2, and a default constructor that requires both to be passed in. It’s important that the values are final – we want to reduce the mutable state at runtime, and assigning the properties during construction allows this.

Ok, now setter injection: if the dependency is optional, meaning we could have a Foo in a valid state without it, then it might be appropriate to inject the dependency with a setter instead. (For some reason, setter injection seems to be the preferred way in Spring – which is wrong.) We could allow a convenience for setter injection as well, simply by adding a default value for that dependency in our “class arguments”:

class Foo(Dependency1 d1, Dependency2 d2 = null) {
}
Foo foo = new Foo(new Dependency1());
foo.d2 = new Dependency2();

Now the default constructor takes only one argument, of type Dependency1, which populates the readonly property d1, and the read/write public property d2 starts off as null. Because it’s a property, outside code can set it. The only aspect that’s missing here is if you want to have additional constructors – but with no additional syntax, you could just write those constructors out in the class body.

The more I have thought about this, the more obvious it seems that injected dependencies of a class are analogous to method parameters, at one scope higher. Why not make the syntax the same, so that this good practice is the easy way? I’d love to hear whether you think this is a good idea.

Tags: injection, nil