Modernized Design Patterns ~ Factory Pattern

In this article, we are going to explore another but a more modernized approach to implement a factory pattern. I divided the article into three sections: when to use the factory pattern, problems of the traditional factory, and the implementation of the suggested approach.

When To Use Factory Pattern

A factory pattern is suggested to be used when your objects have been created based on some condition. Also, don’t forget those objects must have similar functionalities (behaviors), which can be represented by a parent class or an interface. So they should be doing the same thing by doing it in different ways.

For example, all humans can talk, which is something we share. It means that we have similar functionality, talking. But we don’t have to speak the same language, and we might come from different countries. When we start talking, the words we pick, the sentences we construct are going to be different. Even though we are speaking in various ways, we are still doing the same thing, talking.

Suppose we have a class that is responsible for reading a pdf file.

After some while, we had to read an excel document, so we’ve implemented another function. Then another one, and so on.

FileOperations gets bigger and bigger with every new feature, file format, etc. So it’s now time to extract some of those features into another class. Whether you read a pdf, excel, or CSV, you are still reading a file. It means we can represent that behavior with an interface or a more generalized class.

But still, it smells. FileOperations’ readFile() should only care about reading the file, not creating a proper file reader for the extension. The generation of appropriate file reader should be kept hidden (in secret) from the FileOperations. This is the moment when the Factory Pattern steps in.

You end up with the code above when you apply the traditional Factory Pattern.

Problem Of Traditional Factory Pattern

The latest research of Swedish scientists shows a correlation between the understandability of the code and the total number of lines in the class. The graph below summarizes their conclusion.

The problem is evident, as scientists have shown us. The more file readers we have, we have more if-else statements. It increases the total number of lines, which results in an unreadable code.

Suggested Approach

Code snippets are from a Spring Boot project. There are some advantages of using Spring Boot, such as the injection of the singular objects to constructors which I’ve used.

We begin by creating an enum class for file types. It provides us the required information to differentiate between file reader.

After that, we create an abstract parent class for file readers with its children classes.

Don’t worry about the annotations (the ones starts with @). It tells Spring Boot that they are classes that should be created after the application starts.

Spring Boot injects the subclasses of FileReader into the FileReaderFactory constructor. By using an enum map, which is similar to HashMap it just uses an enum as key. We didn’t use any if-else statements in our factory.

Happy Coding!