Generating singletons

Question

This might sound like a weird idea and I haven't thought it through properly yet.

Say you have an application that ends up requiring a certain number of singletons to do some I/O for example. You could write one singleton and basically reproduce the code as many times as needed.

However, as programmers we're supposed to come up with inventive solutions that avoid redundancy or repetition of any kind. What would be a solution to make multiple somethings that could each act as a singleton.

P.S: This is for a project where a framework such as Spring can't be used.

Answer 1

You could introduce an abstraction like this:

public abstract class Singleton<T> {
  private T object;

  public synchronized T get() {
    if (object == null) {
      object = create();
    }
    return object;
  }

  protected abstract T create();
}

Then for each singleton, you just need to write this:

public final Singleton<Database> database = new Singleton<Database>() {
  @Override
  protected Database create() {
    // connect to the database, return the Database instance
  }
};

public final Singleton<LogCluster> logs = new Singleton<LogCluster>() {
  ...

Then you can use the singletons by writing database.get(). If the singleton hasn't been created, it is created and initialized.

The reason people probably don't do this, and prefer to just repeatedly write something like this:

private Database database;

public synchronized Database getDatabase() {
  if (database == null) {
    // connect to the database, assign the database field
  }
  return database;
}

private LogCluster logs;

public synchronized LogCluster getLogs() {
  ...

Is because in the end it is only one more line of code for each singleton, and the chance of getting the initialize-singleton pattern wrong is pretty low.

Answer 2

However, as programmers we're supposed to come up with inventive solutions that avoid redundancy or repetition of any kind.

That is not correct. As programmers, we are supposed to come up with solutions that meet the following criteria:

• meet the functional requirements; e.g. perform as required without bugs,
• are delivered within the mandated timeframe,
• are maintainable; e.g. the next developer can read and modify the code,
• performs fast enough for the task in hand, and
• can be reused in future tasks.

(These criteria are roughly ordered by decreasing priority, though different contexts may dictate a different order.)

Inventiveness is NOT a requirement, and "avoid[ing] redundancy or repetition of any kind" is not either. In fact both of these can be distinctly harmful ... if the programmer ignores the real criteria.

Bringing this back to your question. You should only be looking for alternative ways to do singletons if it is going to actually make the code more maintainable. Complicated "inventive" solutions may well return to bite you (or the people who have to maintain your code in the future), even if they succeed in reducing the number of lines of repeated code.

And as others have pointed out (e.g. @BalusC), current thinking is that the singleton pattern should be avoided in a lot of classes of application.