Abstract Factory Design Pattern

Before we get to the implementation of this design pattern, we will first realise the need for it.

Given a use case of designing a WatchOS system for a smart watch which can be paired with various platforms such as iOS,Android etc

We have features such as playing music, viewing photos on the connected device.Thus, we need different implementation of these features on different platforms as iTunes plays music on Apple Devices whereas we have various music players on Android.

The most naive approach that might come to our minds would include :

• Create an Interface/Abstract Base Class for MusicPlayer and PhotoGallery
• Create concrete classes for both the interfaces and platform(Android,iOS)
• Create a class for applications which would give us a set of applications for a particular platform
• Create a control logic within the application class which decides which platform to serve the object for.

A basic implementation of the above idea is given below:

Though the above implementation helps us achieve what we wanted to, the problem arises when we look to scale the Applications API in watchOS, by adding support for another platform say Windows, we would need to alter the logic inside the application class.

The above situation can be avoided if we decouple the object creation and implementation aspect of it , that is create sub classes for the application class for a particular platform.

The above mentioned intuitive approach to this design case is what we call Abstract Factory Design Pattern.

Our final implementation will include :

• An abstract factory class (ApplicationsFactory), a factory that produces collection of applications for a particular platform
• Concrete Factory Classes for iOS and Android
• A control function that provides with the appropriate factory object for a particular platform(Ruins most of the fun !)

The code for the above mentioned approach

The Basic Structure of an Abstract Factory Design Pattern is given by :

Pic Courtesy: DZone

• In the above structure, we can see that the client only interacts with the abstract factory class and abstract product class , all the implementation is hidden.

In our use case of watchOS we have :

• ApplicationsFactory as our abstract factory interface/base class
• Music Player and Photo Gallery as abstract products and rest all classes are concrete sub classes of the above mentioned abstractions.

What do we achieve with this design?

• There may be cases where we may want to create a set of related products(Music Player, Photo Viewer, Memo etc) that are designed to be used together as a collection. This pattern allows us to do so by enforcing that the collection is used as a single unit.
• We have configured a system with one of multiple collection of products(either Android or iOS), again the pattern ensures that at least one, and only one, of the subset of collection of products will be used at any time.
• This allows our system to have independence between the creation, composition and representation of its products. The pattern provides this by decoupling the implementation of each of these operations.
• We are able to hide the implementations of our products, only revealing the required interface to provide access to their use.

That is it with this design pattern!

Feel free to ask any doubts in the response section.