{"id":31210,"date":"2014-10-07T07:00:41","date_gmt":"2014-10-07T04:00:41","guid":{"rendered":"http:\/\/www.javacodegeeks.com\/?p=31210"},"modified":"2014-10-06T20:24:06","modified_gmt":"2014-10-06T17:24:06","slug":"di-containers-are-code-polluters","status":"publish","type":"post","link":"https:\/\/www.javacodegeeks.com\/2014\/10\/di-containers-are-code-polluters.html","title":{"rendered":"DI Containers are Code Polluters"},"content":{"rendered":"

While dependency injection<\/a> (aka, “DI”) is a natural technique of composing objects in OOP (known long before the term was introduced by Martin Fowler<\/a>), Spring IoC<\/a>, Google Guice<\/a>, Java EE6 CDI<\/a>, Dagger<\/a> and other DI frameworks<\/a> turn it into an anti-pattern.<\/p>\n

I’m not going to discuss obvious arguments against “setter injections” (like in Spring IoC<\/a>) and “field injections” (like in PicoContainer<\/a>). These mechanisms simply violate basic principles of object-oriented programming and encourage us to create incomplete, mutable objects, that get stuffed with data during the course of application execution. Remember: ideal objects must be immutable<\/a> and may not contain setters<\/a>.<\/p>\n

 
\nInstead, let’s talk about “constructor injection” (like in Google Guice<\/a>) and its use with dependency injection containers<\/strong>. I’ll try to show why I consider these containers a redundancy, at least.<\/p>\n

What is Dependency Injection?<\/h2>\n

This is what dependency injection is (not really different from a plain old object composition):<\/p>\n

public class Budget {\r\n  private final DB db;\r\n  public Budget(DB data) {\r\n    this.db = data;\r\n  }\r\n  public long total() {\r\n    return this.db.cell(\r\n      \"SELECT SUM(cost) FROM ledger\"\r\n    );\r\n  }\r\n}<\/pre>\n
The object data<\/code> is called a “dependency”.<\/p>\n
A Budget<\/code> doesn’t know what kind of database it is working with. All it needs from the database is its ability to fetch a cell, using an arbitrary SQL query, via method cell()<\/code>. We can instantiate a Budget<\/code> with a PostgreSQL implementation of the DB<\/code> interface, for example:<\/p>\n
public class App {\r\n  public static void main(String... args) {\r\n    Budget budget = new Budget(\r\n      new Postgres(\"jdbc:postgresql:5740\/main\")\r\n    );\r\n    System.out.println(\"Total is: \" + budget.total());\r\n  }\r\n}<\/pre>\n
In other words, we’re “injecting” a dependency into a new object budget<\/code>.<\/p>\n
An alternative to this “dependency injection” approach would be to let Budget<\/code> decide what database it wants to work with:<\/p>\n
public class Budget {\r\n  private final DB db = new Postgres(\"jdbc:postgresql:5740\/main\");\r\n  \/\/ class methods\r\n}<\/pre>\n
This is very dirty and leads to 1) code duplication, 2) inability to reuse, and 3) inability to test, etc. No need to discuss why. It’s obvious.
 
<\/div> <\/div><\/p>\n
Thus, dependency injection via a constructor is an amazing technique. Well, not even a technique, really. More like a feature of Java and all other object-oriented languages. It’s expected that almost any object will want to encapsulate some knowledge (aka, a “state”). That’s what constructors are for.<\/p>\n
What is a DI Container?<\/h2>\n
So far so good, but here comes the dark side \u2014 a dependency injection container. Here is how it works (let’s use Google Guice as an example):<\/p>\n
import javax.inject.Inject;\r\npublic class Budget {\r\n  private final DB db;\r\n  @Inject\r\n  public Budget(DB data) {\r\n    this.db = data;\r\n  }\r\n  \/\/ same methods as above\r\n}<\/pre>\n
Pay attention: the constructor is annotated with @Inject<\/code><\/a>.<\/p>\n
Then, we’re supposed to configure a container somewhere, when the application starts:<\/p>\n
Injector injector = Guice.createInjector(\r\n  new AbstractModule() {\r\n    @Override\r\n    public void configure() {\r\n      this.bind(DB.class).toInstance(\r\n        new Postgres(\"jdbc:postgresql:5740\/main\")\r\n      );\r\n    }\r\n  }\r\n);<\/pre>\n
Some frameworks even allow us to configure the injector in an XML file.<\/p>\n
From now on, we are not allowed to instantiate Budget<\/code> through the new<\/code> operator, like we did before. Instead, we should use the injector we just created:<\/p>\n
public class App {\r\n  public static void main(String... args) {\r\n    Injection injector = \/\/ as we just did in the previous snippet\r\n    Budget budget = injector.getInstance(Budget.class);\r\n    System.out.println(\"Total is: \" + budget.total());\r\n  }\r\n}<\/pre>\n
The injection automatically finds out that in order to instantiate a Budget<\/code> it has to provide an argument for its constructor. It will use an instance of class Postgres<\/code>, which we instantiated in the injector.<\/p>\n
This is the right and recommended way to use Guice. There are a few even darker patterns, though, which are possible but not recommended. For example, you can make your injector a singleton and use it right inside the Budget<\/code> class. These mechanisms are considered wrong even by DI container makers, however, so let’s ignore them and focus on the recommended scenario.<\/p>\n
What Is This For?<\/h2>\n
Let me reiterate and summarize the scenarios of incorrect usage<\/strong> of dependency injection containers:<\/p>\n