Question

In our project, we have a class KnowledgeBaseManager, which gets used by other classes as follows:

KnowledgeBaseManager manager = KnowledgeBaseManager.get();
manager.foo();

KnowledgeBaseManager holds a static variable standardKnowledgeBaseManager which gets initialized when used for the first time:

class KnowledgeBaseManager {
  private static KnowledgeBaseManager standardKnowledgeBaseManager = null;
  public static KnowledgeBaseManager get() {
    if (standardKnowledgeBaseManager == null) {
      standardKnowledgeBaseManager = new KnowledgeBaseManager();
      // initialize  standardKnowledgeBaseManager with appropriate knowledge base
    }
    return standardKnowledgeBase;
 }

Furthermore, we have a parametrized constructor

public static KnowledgeBaseManager get(OntModel model) {...}

which we use until now just for unit test, where we need a KnowledgeBaseManager with a test knowledge base in the background.

Now, we have the following challenge: For development, we want that the application uses a KB-manager with another knowledge base in the background (because of speed). To be more specific, we build a web application with Wicket. So we want to declare somewhere at the start of the app, which knowledge base and KnowledgeBaseManager is used in the application (depending on wheter we are in development or deployment). The code for using the KB-manager (like

 KnowledgeBaseManager manager = KnowledgeBaseManager.get(); 

now) should not be changed for that.

The question is: what’s the best architecture for that?

I was thinking on using a dependency injection framework like PicoContainer or Guice, but don’t have any experience with it and I am not sure if that would be overhead for that particular problem. Any suggestions for best practices our case?

Answer 1

You are implementing the singleton pattern- and if your code is multithreaded, you are implementing it wrong (see http://java.sun.com/developer/technicalArticles/Programming/singletons/ )

Moreover, as you have discovered, singletons (i.e. global variables) are bad for testing. Dependency injection is one of the answers. Ignore all frameworks first. It means you write your KnowledgeBaseManager in the traditional way- a class with constructor and methods, no static singletonish-factorish methods. Code using KnowledgeBaseManager does not instantiate or lookup the KnowledgeBaseManager- it rather receives it via constructor or setter method (I prefer the former):

public class ClassUsingKnowledgeBaseManager {

  protected final KnowledgeBaseManager knowledgeBaseManager;

  public ClassUsingKnowledgeBaseManager(KnowledgeBaseManager knowledgeBaseManager) {
    this.knowledgeBaseManager = knowledgeBaseManager;
  }

  // ...

}

Note that given that the class does not lookup/instantiate the manager, it does not care whether you are using a singleton or what, and that you can easily instantiate a different manager in your test without touching your code in any way.

After you structure your code in this manner, you might find that you end up with big ugly classes that just instantiate all objects you need, that you need some extra code to tie objects to different scopes (i.e. session or request-scoped objects) and to use config files to control the instantiation… if you find that you are writing lots of repetitive or boilerplate code, you can check out the DI-frameworks, which will probably save you from that.

But for a lot of programs, you might be able to write DI-style code without using a DI-framework.