Correct design of classes built for testability using constructor injection

Question

Say I have these 3 layers of my code:
1. Database layer (ORM)
2. BusinessLogic
3. Application

Now, I write my code as follows:

Database layer:
This mainly has CURD operations over database.

class MyDatabaseLayer {
    public int findValue(int k) {
        // find v
    }

    public void insertValue(int k, int v) {
        // Insert v
    }
}

BusinessLogic:
This holds the actual logic to call database layer and do stuff.

class MyBusinessLogic {
    private MyDatabaseLayer dbLayer;
    public MyBusinessLogic(MyDatabaseLayer dbLayer) {
        this.dbLayer  = dbLayer;
    }

    public int manipulateValue(int k) {
        dbLayer.findValue(k);
        //do stuff with value
    }
}

Application layer:
This calls the business logic and displays the data

MyBusinessLogic logic = new MyBusinessLogic(new MyDatabaseLayer ()); //The problem
logic.manipulateValue(5);

Now if you see in the application layer, it knows about the database layer, which is wrong. It knows too much.

Misko Hevery says: Constructor injection is good. But if I follow that, how will I achieve abstraction? And how can Google Guice help me here?

M. Maraist · Answer 1 · 2011-11-18T01:21:04.117

The part you are missing with inversion-of-control is that the application layer does not call the constructor directly.. It uses a factory (the IoC container) to populate the constructor parameter.

Whatever tool you use, guice / spring / picocontainer / singleton-factories, your application code should look something like:

@Controller
class MyController {
  @Resource // Some container knows about this annotation and wires you in
  MyBusinessLogic myBusinessLogic;

  @RequestMethod("/foo/bar.*")
  public MyWebResponse doService(Response resp, long id, String val) {
     boolean worked = myBusinessLogic.manipulatevalue(id, val);
     return new MyWebResponse(worked);
  }
}

Note, the myBusinessLogic could be registered in several ways - java's @Resource, MyBusinessLogicFactory.getMyBusinessLogic(), guice.get(MyBusinessLogic.class), etc.

A poor-mans solution would be:

package foo;
class MyBusinessLogicFactory {

   static volatile MyBusinessLogic instance; // package-scoped so unit tests can override
   public static MyBusinessLogic getInstance() {
       if (instance == null) {
           synchronized(MyBusinessLogicFactory.class) {
              instance = new MyBusinessLogic(MyDatabaseLayerFactory.getInstance());
           }
       }
       return instance;
   }
}

// repeat with MyDatabaseLayerFactory

Note the above singleton model is highly discouraged, since it has no scope. You COULD wrap the above inside a context - soething like

class Context {
   Map<Class,Object> class2Instance = new ConcurrentHashMap<>();
   public <T> T getInstance(Class<T> clazz) {
      Object o = class2Instance.get(clazz);
      if (o == null) { 
        synchronized(this) {
          o = class2Instance.get(clazz);
          if (o != null) return (T)o;
          o = transitivelyLoadInstance(clazz); // details not shown
          for (Class c : loadClassTree(clazz)) { // details not shown
            class2Instance.put(c, o);
          }
        }
      }
      return (T)o;
   } 
   ...
}

But at that point, picocontainer, guice and spring can solve the complexities of the above SOOO much better.

Further, things like spring that honor the java 6 annotations mean you can do things other than constructor injection, which is VERY useful if you have multiple configuration items of the same base data-type (e.g. strings).

"But at that point, picocontainer, guice and spring can solve the complexities of the above SOOO much better.". Can you elaborate on that part? — zengr, Nov 18 '11 at 18:46

score 1 · Accepted Answer · answered Nov 18 '11 at 13:17

1

Note that for the testability Misko refers to, you ideally want to make interfaces for MyDatabaseLayer, MyBusinessLogic, etc. and have the constructors take those interfaces rather than concrete classes so that in testing you can easily pass in fake implementations that don't actually use the database, etc.

With Guice, you would bind the interfaces to concrete classes in a Module or Modules. You would then create an Injector using those Modules and get some root object (for example, your application object) from the Injector.

Injector injector = Guice.createInjector(new AbstractModule() {
  @Override protected void configure() {
    bind(MyDatabaseLayer.class).to(MyDatabaseLayerImplementation.class);
    // etc.
});
MyApplicationLayer applicationLayer = injector.getInstance(MyApplicationLayer.class);

In MyApplicationLayer, you'd inject the business logic:

@Inject
public MyApplicationLayer(MyBusinessLogic logic) {
  this.logic = logic;
}

This is of course a very simple example and there are much more complex things you can do. In a web application, for example, you can use constructor injection on servlets using Guice Servlet rather than getting an object directly out of the Injector after creating it.

answered Nov 18 '11 at 13:17

ColinD

108,630
30
201
202

Yes, I have interfaces. I just used this example to simplify things. Can you point me to some references for complex examples? – zengr Nov 18 '11 at 18:44
I'd take a look at the Guice [User's Guide](http://code.google.com/p/google-guice/wiki/Motivation) including the stuff on bindings, scopes, extensions, etc. – ColinD Nov 18 '11 at 18:53
Btw, I am dealing with some legacy code where I cannot have an interface for the `MyDatabaseLayer`. Will that be a problem from Guice perspective? – zengr Nov 18 '11 at 19:00
In one of the bindings in the class which extends AbstractModule, I need this: `bind(MyDatabaseLayerImplementation.class).to(MyDatabaseLayerImplementation.class);` since I have no interface. Is this allowed? – zengr Nov 18 '11 at 19:14
You may not be able to change your database class to implement an interface, but can you create an interface and an implementation that delegates to the actual database class? For your second question, if `MyDatabaseLayerImplementation` is a concrete class you don't need to bind it at all... you can if you want though, by just doing `bind(MyDatabaseLayerImplementation.class)`. – ColinD Nov 19 '11 at 02:10
Yeah, I figured that out. Thanks for the help. I am still trying to understand google guice and how can I use it in my application end to end. – zengr Nov 19 '11 at 02:11

Correct design of classes built for testability using constructor injection

2 Answers2