In a framework we deal mainly with abstract classes. Application that is going to use our framework provides the derived classes these abstract classes.

Let’s understand by an example of Thread pooling Framework,

A thread pooling framework provides the facility to execute Tasks in pooled environment by worker threads. It’s doesn’t know what actually the Task is, it just provides the facility to run this Task.

So, Task here is an abstract class.

Framework also uses an abstract class TaskFactory to create the Task objects. In application, Task objects can be created based on any xml file, json file or through any other input channel. But that framework doesn’t need to know that, because that completely depends on application that is using this framework.

Framework deals only with an abstract class TaskFactory to create Task objects.

Remember frameworks main responsibility is,

  • Storing Tasks in waiting queue.
  • Executing Tasks through worker Threads.
  • Providing the output of executed Tasks.

Framework is not interested in,

  • What exactly is the Task
  • How to create Task Objects

Therefore, Framework will use two Abstract classes,

1.) Task

It’s an abstract class that contains an abstract function execute(). Framework will use this abstract class to deal with all types of Tasks.

 

2.) TaskFactory

It’s an abstract class that is used by framework to generate different Task objects. Which actual Task should be generated is decided by classes derived from TaskFactory.

Classes derived from Task and TaskFactory classes are provided by application that is using this framework.

Factory Method Design Pattern

This is the perfect case to use Factory Method Design Pattern.

Intent of Factory Method Design Pattern

Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.

A factory method design pattern should be used when,

  • A class is assigned with responsibility to create an object of an Abstract class but it doesn’t know the actual derived class of objects it must create.
  • A class wants its subclasses to specify the objects it creates.

Now in our application i.e. using this framework, have two types of Tasks i.e.

EMailTask :

  • Derived from Task.
  • This will send the mail to a specified user.

SMSTask :

  • Derived from Task.
  • This will send the SMS to a specified user.

Now two create the objects of these two types of Tasks we have to Two factory classes,

EMailTaskFactory :

  • Derived from TaskFactory
  • It overrides the factory method to return an instance of a EMailTask object.

SMSTaskFactory :

  • Derived from TaskFactory
  • It overrides the factory method to return an instance of a SMSTask object

Here getTaskObject is the factory method.

Now consider this is a dummy code of our framework,

Here this framework function is accepting a TaskFactory pointer. From this TaskFactory pointer it is creating a Task object and calling the execute function.

As, it’s a framework code it doesn’t know which Derived TaskFactory class object was inside this TaskFactory pointer and which Task was actually created.  Both of this was managed by the code of our application i.e.

Advantage of using Factory Method Design Pattern:

Frameworks don’t need to use application-specific classes, its code deals with the interfaces of Products only. Therefore it can work with any user-defined Derived / concrete classes.

Disadvantage of using Factory Method Design Pattern:

For every concrete class of Product application needs to provide a Factory class like, although this can be prevented by using templates i.e.

Keep looking for more on Design Patterns.

Click Here to Subscribe for more Articles / Tutorials like this.