Abstract Factory Pattern with Examples

Today, I will talk about highly popular Abstract Factory Pattern. Please note I am not going to take any Animal or Shape example as they don’t fit in the real-world development. Rather, I would take two different examples, one from .NET framework itself and another from my own work. To start with let’s see the definition of the pattern first.

“Provides an interface for creating families of related or dependent objects without specifying their concrete classes.”

“Abstract Factory Pattern provides a way to encapsulate a group of individual factories that have a common theme.“

Remember the term related and dependent objects in the above definition. By the end of this blog you would have a good understanding of how objects are related.

Structural UML

1. AbstractFactory defines the interface that all of the concrete factories will need to implement in order to serve Products. 
2. ConcreteFactoryA and ConcreteFactoryB have both implemented this interface creating two seperate families of product.
3. AbstractProductA and AbstractProductB are interfaces for the different types of product. Each factory will create one of each of these AbstractProducts. 
4.  Client deals with AbstractFactory, AbstractProductA and AbstractProductB. It doesn’t know anything about the implementations. The actual implementation of AbstractFactory that the Client uses is determined at runtime.

One of the very known example is from ADO.NET

1. Here ADO.NET defines an abstract product class DbConnection. For which we have several concrete products SqlConnection and OracleConnection etc. And these classes implements DbConnection.

2. Similarly, DO.NET defines an abstract product class DbCommand. For which we have several concrete products SqlCommand and OracleCommand etc. And these classes implements DbCommand.

3. DbProviderFactory class is the abstract factory class to help us to implement a Provider-Independent. The abstract factory, DbProviderFactory, declares a set of CreateXxx Methods,like, CreateConnection, CreateCommand etc.

4. Each of these methods return a specific abstract product, for example CreateConnection returns DbConnection, CreateCommnad return DbCommand etc…

5. DbProviderFactory has a set of concrete factory classes such as SqlClientFactory, OracleClientFactory etc…These concrete factories implements the CreateXxx methods to return specific products-provider specific classes.

Now, let’s take another hands on example of TextReader and TextWriter.

Assume your project demands to read and write texts to and from CSV format and MS Excel format. If I ask a beginner or a less experienced developer to write code for this, then he would probably end up with creating to classes one for CSV and another for MS excel. Each having two methods for Read and Write operations. I am not saying this is wrong but rather we have a better and maintainable approach for such requirements.

From the above requirement, We have two abstract products TextReader and TextWriter. So I’ll create ITextWriter (Interface) and TextReader(AbstractClass). Just for the sake of example I am going to create two different types to showcase that abstraction can be achieved from both interface and abstract classes.

Now let’s create four actual product implementation classes (concrete products). CSVTextReader, CSVTextWriter, ExcelTextReader and ExcelTextWriter which implements abstract product classes. These classes are required to override ReadImplementation and WriteImplementation methods

Once our products classes are ready we can create two concrete factories CSVTextReaderWriterFactory and ExcelTextReaderWriterFactory each having two methods GetReader and GetWriter. Please note how factories are returning related objects to the client. This is similar to a scenario where two different garment brands producing Shirt and a Trouser. In our case CSV and Excel are brands and TextReader and TextWriter are shirt and trouser respectively.

And finally let’s write a method to run the code. I could have created a separate FactoryMaker to instantiate a factory. But I am leaving it up to you to write it.

There is one another great example which talks about building UI elements on different platforms. This will also help you to understand the pattern in more details. https://dzone.com/articles/design-patterns-abstract-factory

Advantages of Abstract Factory:

• Isolation of concrete classes:
  The Abstract Factory pattern helps you control the classes of objects that an application creates. Because a factory encapsulates the responsibility and the process of creating product objects, it isolates clients from implementation classes. Clients manipulate instances through their abstract interfaces. Product class names are isolated in the implementation of the concrete factory; they do not appear in client code.
• Exchanging Product Families easily:
  The class of a concrete factory appears only once in an application, that is where it’s instantiated. This makes it easy to change the concrete factory an application uses. It can use various product configurations simply by changing the concrete factory. Because an abstract factory creates a complete family of products, the whole product family changes at once.
• Promoting consistency among products:
  When product objects in a family are designed to work together, it’s important that an application use objects from only one family at a time. AbstractFactory makes this easy to enforce.

Disadvantages of Abstract Factory:

• Difficult to support new kind of products:
  Extending abstract factories to produce new kinds of Products isn’t easy. That’s because the AbstractFactory interface fixes the set of products that can be created. Supporting new kinds of products requires extending the factory interface, which involves changing the AbstractFactory class and all of its subclasses. But you can overcome this problem by using reflection in .Net Framework and defining CreateProduct method in the AbstractFactory class.