Curse of the Dependency Injection Framework

Dependency injection is, of course, a useful technique, but it’s also incredibly trivial. Most engineers have been using DI for their entire careers, long before this trivial construct was given a silly name. But then again a morning meeting is now called a “daily scrum”, an open plan office a “bull pen”, a period of work a “sprint” and the annoying guy looking over your shoulder and nit-picking at every line of code you write is not the office psychopath, he’s just “extreme programming”. Welcome to the bizarre world of geek speak. A world in which men (and I use the term loosely) who have spent far too many hours in front of an LED screen and far too few with the opposite sex seek to raise their societal status by assigning ridiculous words to common everyday occurrences. And if all this wasn’t bad enough, now enter the framework: a large, cumbersome configuration system that does, well, basically nothing.

First let’s examine the trivial construct of DI. DI is simply the act of passing one object into another, eg.

class S {
  privte I i;
  public S(I i) {
    this.i = i;
  }
  public String f() {
    return i.f();
  }
}

I i = new I();
S s = new S(i); //  <- Dependency injection!

Yes, that trivial single line is what all the fuss is about. The basic reason to do this is simply because we are modelling a situation where the host object s does not know how to instantiate i. Typically I may also be an interface such that various different types of I can be passed to s. Also, typically, one implementation may be a real “live” implementation L whilst another may be mock for testing T.

interface I {
  String f();
}

class L implements I {
  public String f() { 
    return "live"; 
  }
}

class T implements I {
  public String f() { 
    return "test"; 
  }
}

S sl = new S(new L());
S st = new S(new T());

So, it’s pretty clear and very trivial that DI can be performed in simple Java. No frameworks or XML config files are needed to achieve this. The service S can be set up for either live purposes or for unit tests with mock dependencies. During a unit test an example setup may be to use the @Before annotation:

private S s;

@Before
void before() {
  s = new S(new T());
}

@Test
void test() {
  assertEquals("test",s.f());
}

In a live application an example setup may be:

static void main() {
  S s = new S(new L());
  println(s.f()); // Prints "live"
}

It can be clearly seen that there is absolutely no need for any type of framework whatsoever in order to achieve the required goals.

Suppose s is a servlet running inside a JEE container then in this case the JEE container is responsible for instantiating s. A little more work is therefore required to set up s. A “live” service class LS is derived from S such that it constructs s with the relevant “live” dependencies. LS is then used as the actual servlet and of course S remains testable as before.

class LS extends S {
  public LS() {
    super(new L());
  }
}

It can therefore be clearly seen that the trivial notion of DI can be easily implemented without the use of any type of framework and simply by using standard and simple Java code. Nevertheless, a great many engineers still insist on using large and cumbersome frameworks such as Spring to perform this trivial task, somehow under the misguided belief that this is the only way to achieve DI. Personally I have yet to meet a single engineer who can properly justify his rational for using Spring and I have never see a piece of DI framework code that cannot be written more simply and more concisely in plain Java.

Spring has indeed become a curse. It is slow and cumbersome, but worst of all it requires code that would have ordinarily been written in Java to be migrated to XML configuration files. It goes without saying that XML is not compiled or type checked as Java is, and therefore it creates an extremely brittle and difficult to follow architecture. It is a truly bizarre state of affairs that almost the entire Java community has resolved to deliberately make life very difficult for themselves in what appears to be a typical case of groupthink, a monolythic body of unthinking developers blindly following the rantings of the Spring officionados.

Eventually Spring will die because in the end reality will finally dawn, but until then the Java world will continue to be cursed by the dependency injection framework.

Advertisements
Curse of the Dependency Injection Framework

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s