Overview #

In Part 2 of the singleton tutorial, we examined a thread-safe singleton implementation for the Config service. We also covered the use of private constructors to prevent unintended instantiation of the Config and DataStoreFactory classes, and the final keyword to avoid unintentional subclassing and method overriding.

When comparing the DataStoreFactory factory pattern and the singleton pattern, one might argue that a fully static implementation of the Config service would achieve the same goal, ensuring that no two instances of Config exist, thus providing a resource-efficient implementation. So, what distinguishes the factory method pattern from the singleton pattern, and when should we use one over the other?

Singleton Polymorphism #

The singleton pattern has an advantage over the factory pattern with static factory methods in that it allows polymorphism, i.e., it allows instantiating different configuration services for development and production. For example, configuration could be read from app.properties in development but from a Redis key-value store in production. Ideally, we would not want to distinguish between the two in the application. Instead, we would use polymorphism to provide the different solutions.

The following approach presents a way to implement a flexible configuration service. We use the existing app.properties configuration file to determine the environment we are running in. Based on the environment, we either instantiate a PropertiesConfig or a RedisConfig in our Config.getInstance() method.

public class Config {

    ...

    public final static Config getInstance() {
        if (instance == null) {
            synchronized (Config.class) {
                if (instance == null) {
                    switch (getEnvironment()) {
                        case
                                ENVIRONMENT_DEVELOPMENT,
                                ENVIRONMENT_TEST:
                            instance = new PropertiesConfig();
                            break;
                        case
                                ENVIRONMENT_PRODUCTION:
                            instance = new RedisConfig();
                            break;
                        default:
                            throw new IllegalStateException("invalid environment");
                    }
                }
            }
        }
        return instance;
    }

    ...

}

Because Config.getInstance() is a static class method and we can only call static class methods from within another static class method, getEnvironment() needs to become a static class method as well.

public class Config {

    ...

    public final static String getEnvironment() {
        var value = properties.getProperty(ENVIRONMENT);

        ...

    }

    ...

}

Now, getEnvironment() needs to get access to the properties object. Again, static methods can only access static class variables, hence, we need to make properties static as well. As a result, properties can only be available once among all objects of Config. This is ok because we anyway have only one instance of the Config class and consequently properties is not required to be an instance variable. However, class variables cannot be initialized within a constructor because they belong to the class and not to an object of the class. There simply is no constructor for a class in Java where class variables could be initialized. Nevertheless, class variables need to be initialized after the class is loaded by the ClassLoader. In Java, a static initialization block is the means to initialize class variables. In other words, a static initialization block is to class variables what a constructor is to instance variables.

public class Config {

    ...

    static final Properties properties;

    static {
        properties = new Properties();
        try {
            properties.load(Config.class.getClassLoader().getResourceAsStream(CONFIG));
        } catch (Exception e) {
            throw new IllegalStateException("could not load app.properties", e);
        }
    }

    ...

Please notice that we make the properties class variable package private by omitting any access modifier. This prohibits access to properties in subclasses of Config when the subclass is not located in the same package. In the static initialization block we now again use the ClassLoader approach to load the app.properties configuration file.

With this approach, the environment configuration is always loaded from app.properties, however, the database configuration is loaded from the respective implementation, either a PropertiesConfig class or a RedisConfig class.

To specify that, we make the getDatabase() method abstract so that it needs to be implemented by the respective subclass. Consequently, we need to make the Config class abstract as well.

public abstract class Config {

    ...

    public abstract String getDatabase();

}

Next, we implement the PropertiesConfig which extends our Config class and implement the getDatabase() method.

public final class PropertiesConfig extends Config {

    ...

    private static final String DATABASE = "database";

    ...

    PropertiesConfig() {
    }

    ...

    @Override
    public final String getDatabase() {
        ...
    }

    ...

}

We make the PropertiesConfig constructor package private again by omitting the access modifier so that our Config class has access to the constructor but other classes outside the package do not. Moreover, we make the PropertiesConfig class final to again prohibit unintentional subclassing of the PropertiesConfig class. Equally, we prohibit unintentional overriding of the getDatabase() method using the final modifier.

With respect to the RedisConfig class we currently only implement an empty class body and leave the concrete implementation for later.

public final class RedisConfig extends Config {

    RedisConfig() {
        // TODO Auto-generated method stub
        throw new UnsupportedOperationException("Unimplemented 'RedisConfig'");
    }

    @Override
    public final String getDatabase() {
        // TODO Auto-generated method stub
        throw new UnsupportedOperationException("Unimplemented method 'getDatabase'");
    }

}

Model #

With these modifications, the class diagram looks as follows.

Summary #

In this tutorial, we explored how to implement a flexible configuration service using the singleton pattern. By leveraging polymorphism, we can seamlessly switch between different configuration sources based on the environment. This approach ensures that the application remains adaptable and maintainable, regardless of the underlying configuration mechanism.