Part 2

Overview #

In singleton tutorial Part 1 we introduced a configuration service to customize creation logic of the DataStoreFactory.

Implementation Issues #

However, looking in detail at the configuration service Config and the factory DataStoreFactory, we can observe several issues.

public class Config {

    ...

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

    ...

}

...

public class DataStoreFactory {

    public static DataStore getDataStore() {

        final Config config = new Config();

        switch (config.getEnvironment()) {
            case Config.ENVIRONMENT_DEVELOPMENT:
                return new TextFileDataStoreImpl(config.getDatabase());
            case Config.ENVIRONMENT_TEST:
                return new MockDataStoreImpl();
            case Config.ENVIRONMENT_PRODUCTION:
                return new DatabaseDataStoreImpl(config.getDatabase());
            default:
                throw new IllegalStateException("unknown environment: " + config.getEnvironment());
        }

    }

    public static DataStore getDataStore(DataStoreType type, String connectionString) {
        switch (type) {
            case DATABASE:
                return new DatabaseDataStoreImpl(connectionString);
            case TEXTFILE:
                return new TextFileDataStoreImpl(connectionString);
            case MOCK:
                return new MockDataStoreImpl();
            default:
                throw new IllegalArgumentException("Unknown data store type");
        }
    }

}

  1. Repeated instantiation of configuration instances Each time the DataStoreFactory.getDataStore() method is called, a new instance of the Config service is created. This results in multiple objects being created and the configuration being read from the filesystem every time the method is invoked. To optimize this, we could make Config a private property of DataStoreFactory and instantiate it only once per factory. However, in real-world scenarios, configuration services are usually shared across multiple classes. Creating a private instance of the configuration service for each client would be inefficient and resource-intensive.

  2. Repeated instantiation of DataStoreFactory DataStoreFactory only contains static methods. Static methods in Java belong to the class rather than any instance, meaning they can be called on the class itself without needing to create an object. They are defined using the static keyword and can only access static data members and other static methods directly. However, with the current implementation, it is not prevented that users of DataStoreFactory can create instances of it. Instantiating objects for a class that only contains static methods is a waste of resources.

  3. Repeated instantiation of Config Similarly, with the current implementation of Config it is not prevented that users of the service create multiple instances of Config which again is a waste of resources.

  4. Inheritance and Method Override Both DataStoreFactory and Config can currently be inherited and methods can be overridden. In real-world applications, it is generally advisable to prevent inheritance and method overrides for such central components. Factories and configuration services are critical parts of the codebase, and allowing them to be extended can introduce unintended side effects.

Singleton Pattern #

In the following, we introduce the singleton pattern as a solution for Issues 1 and 3. The singleton pattern ensures that only one instance of a class is created, preventing multiple instantiations.

Firstly, we make the constructor of the class private. This prevents any other code from instantiating an object from the class.

public class Config {

    ...

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

    ...

}

Secondly, we create a static class method getInstance() that can be called on the Config class. getInstance() checks whether an instance of Config has already been created by keeping a reference to the instance in a private static class variable. A new instance of Config is created only when it was not created yet, i.e., the private static class variable instance is null and hence was not already assigned an instance of Config.

public class Config {

    ...

    private static Config instance;

    public static Config getInstance() {
        if (instance == null) {
            instance = new Config();
        }
        return instance;
    }

    ...

}

The above implementation works in single-threaded applications but could have side effects in multi-threaded applications where a Config instance is created within two parallel threads at the same time. There are multiple solutions for making getInstance() thread-safe - the following is one of them.

public class Config {

    ...

    public static Config getInstance() {
        if (instance == null) {
            synchronized (Config.class) {
                if (instance == null) {
                    instance = new Config();
                }
            }
        }
        return instance;
    }

    ...

}

First, we check if an instance has not already been created and assigned to instance. Then we wrap the instantiation within a synchronized block. Because between the first if (instance == null) and the synchronized statement a parallel thread might already have created an instance of Config, we need to check if (instance == null) within the synchronized block again.

The synchronized keyword can be seen as a question to a “gatekeeper” of a room, asking if the room is currently occupied or not. The “gatekeeper” would only let one in if the room is free. If it is occupied, the “gatekeeper” would require one to wait until the room is free again. Obviously, this “gatekeeper” needs to be always the same, i.e., every thread in the system needs to ask exactly the same “gatekeeper” whether the room is occupied or not.

In our example, we use Config.class as the “gatekeeper”. Config.class is a class variable of the Config class and returns an object that contains metadata about the Config class itself. Any class in Java has the .class class variable. Because a class is loaded only once in a system by the same ClassLoader, exactly one instance of Config.class exists in the system. Hence, using Config.class as the “gatekeeper” ensures that we always ask the same “gatekeeper”.

However, synchronized would accept any other object as well. It is in the responsibility of the developer to pass an object to synchronized that is unique for all threads in the system that would make use of the code within the synchronized block.

Final Classes and Methods #

To provide a solution for issues 2 and for and hence to prevent a class from being inherited and its methods from being overridden, Java provides the final keyword for classes and methods. Declaring a class as final ensures that it cannot be subclassed. Similarly, declaring a method as final ensures that it cannot be overridden by subclasses.

With these optimizations, our DataStoreFactory and Config classes look as follows:

public final class Config {

    ...

    public static final Config getInstance() {
        if (instance == null) {
            synchronized (Config.class) {
                if (instance == null) {
                    instance = new Config();
                }
            }
        }
        return instance;
    }

    private Config() {
        ...
    }

    ...

}

...

public final class DataStoreFactory {

    private DataStoreFactory() {
    }

    public static final DataStore getDataStore() {
        final Config config = Config.getInstance();
        ...
    }

    public static final DataStore getDataStore(DataStoreType type, String connectionString) {
        ...
    }

}

Using Config.getInstance(), we ensure that only one instance of Config is created in a thread-safe manner, irrespective where and in which part of the whole application Config.getInstance() is called. Moreover, both Config and DataStoreFactory classes have private constructors to prevent instantiation. Finally, both classes are declared final to prevent unintentional inheritance, and their static methods are declared final as well to prevent them from being overridden unintentionally.

Model #

With these modifications, the class diagram looks as follows.

class diagram

Summary #

In this tutorial, we addressed several implementation issues in the Config and DataStoreFactory classes, such as repeated instantiation and potential inheritance problems. We introduced the singleton pattern to ensure that only one instance of Config is created, making it thread-safe and efficient. Additionally, we used the final keyword to prevent inheritance and method overrides, ensuring the integrity of these critical components. These optimizations enhance the performance and reliability of the configuration and factory services in the application.