•
24min

Mastering the Factory Method Design Pattern: Building a Task Management CLI

Sidali Assoul

Sidali Assoul

@sidali_assoul

Mastering the Factory Method Design Pattern: Building a Task Management CLI (placeholder)Mastering the Factory Method Design Pattern: Building a Task Management CLI

Have you encountered a case where the creation of an object or a family of objects in your application requires some kind of business logic which you don't want to just repeat over and over in your application?

Or have you ever built an application, got it done after a lot of hustle, then discovered that you misunderstood a requirement or maybe your client just changed their mind, and now you need to refactor all the business logic which creates your application objects?

What if there was a way to just swap the previous implementation with the new one, just by changing a few lines of code?

Well, that's where the Factory Method design pattern comes in!

Throughout this tutorial, we will be demystifying this Design Pattern while building a fully functional Task Management Node.js CLI Application!

Overview

Factory Method is a creational design pattern, which is a category of design patterns that deals with the different problems that come with the native way of creating objects with the new keyword or operator.

Problem

The Factory Method Design pattern focuses on solving the following problems:

  1. The creation of many objects using the new operator may require complex business logic, to either determine the correct instance which should be created or the necessary parameters for that instance.

  2. Refactoring the calls to the new operator to instantiate our entities requires modifying all the references in our code, which makes introducing new types of objects hard and time-consuming.

If you needed to introduce a new type of object or change the existing business logic for creating a specific entity, you would have to refactor all of the creational code which is spread across your codebase.

Solution

The Factory Method Design pattern solves these problems by moving the objects creation responsibility into special classes called Factories.

Instead of spreading the creational code for each type of object in our application and using the new operator to instantiate them, we call these classes known as Factories.

Each Factory contains a method which is responsible for creating a new instance of a specific type of object, which is the reason for naming this design pattern factory method.

The factory design pattern provides an interface for creating objects of a specific type (IProduct) in a superclass (interface or abstract class) named Factory while allowing subclasses (ConcreteFactories) to alter the type of the returned objects (ConcreteProducts).

So if you needed to change the creation business logic or the type of objects which is returned by the factory method calls, you just have to change one line of code.

Each concret factory is free to return any type of concret products as long as they implement the IProduct interface.

Structure

Factory Design Pattern Schema

The structure of the factory design pattern consists of the following classes:

  1. Factory: an interface (or abstract class) which declares the factory method (create). You can think of it as the generic factory or the superclass of all the ConcreteFactories. The factory method returns an IProduct which is a common type between all the products which can be made by the factory.

  2. ConcreteFactory: The concrete factory extends/implements the Factory, overrides the factory method (create) and returns a sub-type of the IProduct interface (ConcreteProducts).

  3. IProduct: is the common interface which will be implemented by many ConcreteProducts.

  4. ConcreteProduct: a class which is an IProduct.

Practical Scenario

Now let's put this design pattern into practice by building a fully working Task Management Node.js CLI app.

You can find the final code in this repository. Just clone it and run the following commands.

First install dependencies

Then run the cli app

After running the CLI app, you will see this menu list which shows the different options you can perform in this application:

  1. Add a task.
  2. List the created tasks.
  3. Complete a task by toggling its status.
  4. Switch between two modes: Priority based mode and standard mode. And guess what? We will be switching between factories:
  • A StandardTaskFactory
  • A PriorityBasedTaskFactory

Each factory will be following its own way or business logic for creating different types of tasks: Simple, Urgent, and Recurring.

Factory Method Demo: Task Management CLI App

Declaring our Types

So let's start by declaring our types:

types.ts

We've defined some utility types that we will be using in our CLI app such as:

  • TaskType: A union type for storing all the types of tasks.
  • TaskAnswers: When our CLI app asks the user for some inputs, we will be storing the result in an object which satisfies this type.

Now let's define our common task interface, which will be an abstract class in our case because we want to share some common attributes, like: description, id, and completed between our ConcreteTasks.

The decision of choosing an interface or abstract class for your common type depends on the use case. If you needed to just share method signatures between your subtypes, use an interface. But if you have some shared attributes between your types or maybe you want to provide some default implementations for some methods, then use an abstract class.

Creating the task common type

Task.ts abstract Task

Creating Concrete Tasks

Next, let's declare our concreteTasks classes, which will be implementing the Task abstract class and overriding some methods' behavior (SimpleTask and UrgentTask) or adding some extra attributes like nextDueDate for the RecurringTask.

Task.ts Concrete Tasks

Declaring The Generic Factory

Now, it's time for declaring the generic Factory type for creating tasks.

TaskFactory.ts

In the above code, we've declared the TaskFactory which is the common or parent type of all our factories.

The generic factory comes with:

  • An abstract factory method named createTask.
  • An abstract determineTaskType method which will contain the business logic for determining the type of a task based on various parameters such as: description, dueDate, priority, isRecurring, and interval.
  • A protected method named calculateDaysUntilDue which comes with a default implementation for calculating the days until the due date for a given task.

The utility methods declared next to the factory method will be used inside the implementation of the factory method next to the task creation business logic.

Our factory won't be just a stateless factory, but it will keep track of the following states which will be updated every time a Task gets created.

  • nextId: the next integer id which will be assigned to the upcoming task.
  • taskCount: is a map storing the created task types counts.
  • lastCreatedTaskType: the factory is keeping track of the last created task in this state variable.

The reason behind storing the counts is to give the ConcreteFactories the ability to alter their decisions about the task type based on the distribution of the already created tasks by type.

Creating The Concrete Factories

Now let's move on to the ConcreteFactories code.

We will be creating two kinds of factories: StandardTaskFactory and PriorityBasedTaskFactory.

Each concrete factory will be extending the Task Generic Factory and overriding it as needed while returning the chosen task type based on a custom business logic.

Depending on the determined task type, the factory will instantiate the corresponding Task instance: SimpleTask, UrgentTask, and RecurringTask.

The StandardTaskFactory will be mainly using the following metrics:

  • The presence of isRecurring and interval variables.
  • Is the priority interval greater than 8.
  • Are the daysUntilDue lower than 2.
  • Does the description of the task contain the keywords: urgent or important
  • Is the urgent tasks count surpassing the simple tasks count by a factor of two.
  • If the lastCreatedTaskType is urgent, there is a 70% probability that the next created task is simple.

TaskFactories.ts StandardTaskFactory

On the other hand, the PriorityBasedTaskFactory is using the following metrics:

  • The presence of isRecurring and interval variables.
  • Is the priority interval greater than 8.
  • Is the priority interval greater than 5 and less than 8.
  • Are the daysUntilDue lower than 5.

TaskFactories.ts PriorityBasedTaskFactory

The Task Manager Class

  • The TaskManager class stores the generic Tasks in a local array property named tasks.
  • It takes a generic TaskFactory as a constructor argument.
  • It's providing many methods for manipulating the tasks:
  • addTask for creating a new task using the generic factory which it got from the constructor.
  • listTasks goes through all the generic tasks in the tasks array and prints their status via the getStatus method which is shared between the generic tasks instances.
  • completeTask marks a task as completed.

TaskManager.ts

The CLI Class

The CLI is responsible for showing a menu which displays various options then asking the user to choose among various options such as:

  • Add Task: adding a new task.
  • List Tasks: displaying all the created tasks with their completion status and type.
  • Complete Task: completing a task given its unique ID.
  • Switch Priority Mode: switching between the priority mode.
  • Exit: Exiting the program.

The CLI class instantiates the task manager class while passing the current active factory. By default, we are passing an instance of the StandardTaskFactory.

When the user decides to choose the Switch Priority Mode option, we prompt them to select the factory instance which they would like to use.

cli.ts

Finally, the index.ts file just instantiates the CLI class then calls the start method on the instantiated CLI object.

index.ts

Conclusion

In this tutorial, we've explored the Factory Method design pattern and its practical implementation in a Task Management CLI application. By using this pattern, we've created a flexible and extensible system that can easily accommodate different types of tasks and task creation strategies.

The Factory Method pattern allows us to:

  1. Encapsulate object creation logic in separate classes (factories).
  2. Easily switch between different object creation strategies at runtime.
  3. Maintain a clean separation of concerns between object creation and object use.
  4. Extend the system with new types of tasks or creation strategies without modifying existing code.

By implementing this pattern in our Task Management CLI, we've demonstrated how it can be used to create a more maintainable and adaptable codebase. This approach is particularly useful in scenarios where the types of objects being created might change over time, or where the creation logic might vary based on different conditions or user preferences.

As you continue to develop and expand your applications, consider how the Factory Method pattern and other design patterns can help you create more robust, flexible, and maintainable code.

Contact

If you have any questions or want to discuss something further feel free to Contact me here.

Happy coding!

Deep dive into Orien...Git Merge vs. Rebase...
See all postsSee all posts