Overview #

In this tutorial, we will explore the Factory Pattern in Java using the DataStore interface and its implementations DatabaseDataStoreImpl, TextFileDataStoreImpl, and MockDataStoreImpl from the previous Part 1 of this tutorial series.

In the diagram above, the NewsAgency constructor does not allow for injecting an implementation of the DataStore interface. Consequently, NewsAgency must instantiate a DataStore implementation within its constructor, leading to direct dependencies on DatabaseDataStoreImpl, TextFileDataStoreImpl, and MockDataStoreImpl. This results in tightly coupled code, which we aim to avoid.

To address this tight coupling, we can use the Factory Pattern. This creational design pattern centralizes the creation of objects, allowing dependencies on DataStore implementations to be shifted from the users of DataStore to a dedicated factory. In addition, this approach enables changes to the types of created objects with minimal impact on the client code that utilizes these objects.

Review of DataStore Interface and Implementations #

The DataStore interface defines a contract for loading news data based on a date. Here are the implementations of this interface:

1. DatabaseDataStoreImpl: This class connects to a database to load news data.
2. TextFileDataStoreImpl: This class reads news data from a text file.
3. MockDataStoreImpl: This class provides mock news data, useful for testing purposes.

Factory Pattern Explanation #

The Factory Pattern involves creating a factory class that decides which implementation of the DataStore interface to instantiate based on some input parameters. This pattern helps in decoupling the client code from the concrete classes, making the code more flexible and easier to maintain.

Example Factory Class in Java #

Here is an example of how you can implement the Factory Pattern in Java using the DataStore interface and its implementations, along with an enum to represent the different types of data stores:

public interface DataStore {
    List<String> loadNews(Date date);
}

public class DatabaseDataStoreImpl implements DataStore {
    ...
}

public class TextFileDataStoreImpl implements DataStore {
    ...
}

public class MockDataStoreImpl implements DataStore {
    ...
}

public enum DataStoreType {
    DATABASE,
    TEXTFILE,
    MOCK
}

public class DataStoreFactory {

    ...

    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");
        }
    }

}

Please note the use of the static keyword before the getDataStore factory method. In Java, static methods are associated with the class itself and operate in the context of the class. These methods are also known as Class Methods. Class Methods can be called without creating an instance of the class. For example, the getDataStore method can be called as DataStoreFactory.getDataStore(DataStoreType.DATABASE, "jdbc:sqlite:db").

With the introduction of the factory pattern into our newsbroker example, the class diagram looks as follows.

The NewsAgency class can now utilize the DataStoreFactory to instantiate the appropriate DataStore implementation without needing to know the specifics of DatabaseDataStoreImpl, TextFileDataStoreImpl, or MockDataStoreImpl. This decouples the NewsAgency from the concrete DataStore implementations, promoting a more flexible and maintainable design.

Factories can be used as a standalone concept to decouple code or in combination with the Inversion of Control principle. In the latter case, a factory would not be used within the constructor of the class that uses a specific module, such as the Datastore in NewsAgency, but in the initialization code of the application, e.g., in the main() method.

It is good practice to use the Inversion of Control principle in combination with the factory pattern so that NewsAgency does not even need to know about the factory.

In the updated diagram, the NewsAgency constructor can accept an implementation of the DataStore interface. During initialization, such as in the main() method, a specific DataStore implementation is instantiated and injected into the NewsAgency constructor. This approach achieves maximum decoupling between NewsAgency and the DataStore implementations while centralizing object creation within the factory.

public static void main(String[] args) {

    ...

    var datastore = DataStoreFactory.getDataStore(DataStoreType.DATABASE, "jdbc:sqlite:db")
    var apa = new NewsAgency(datastore, "reuters")

    ...

}

The App class finally wires up the whole application

according to following object diagram

leaving a clean and decoupled application architecture.

Why Use the Factory Pattern? #

• Encapsulate Object Creation: The Factory Pattern hides the instantiation logic from the client, promoting loose coupling. This means that the client code does not need to know the specifics of how objects are created, only that they are created.

• Promote Code Reusability: By centralizing the object creation logic in a single place, the Factory Pattern avoids code duplication. This makes it easier to reuse the object creation code across different parts of the application.

• Enhance Flexibility: The Factory Pattern allows the system to introduce new types of objects without changing the client code. This makes it easier to extend the system with new functionality without modifying existing code.

• Improve Maintainability: Changes in object creation logic need to be made in one place, reducing the risk of errors. This makes the code easier to maintain and reduces the likelihood of bugs when changes are made.

By using the Factory Pattern, you can achieve a more modular, flexible, and maintainable codebase, which is easier to extend and less prone to errors.

Summary #

In this tutorial, we explored the Factory Pattern and its implementation using the DataStore interface and its various implementations. We demonstrated how to use a simple factory class to create instances of different DataStore implementations based on input parameters. This pattern enhances the flexibility and maintainability of the code by decoupling the client code from the concrete classes.