Overview

The Abstract Factory Pattern is known as a creational pattern. Abstract Factory patterns work around a super-factory which creates other factories.

It provides an interface for creating families of related or dependent objects without specifying their concrete classes.

It has a level of indirection that abstracts the creation of families of related or dependent objects without directly specifying their concrete classes.

The “factory” object has the responsibility for providing creative services for the entire platform family. Clients never create platform objects directly, they ask the factory to do that for them.

This mechanism makes exchanging product families easy because the specific class of the factory object appears only once in the application – where it is instantiated.

The application can wholesale replace the entire family of products simply by instantiating a different concrete instance of the abstract factory.

Let’s understand Problem and Solution with Example

There is a multi-cuisine restaurant. They have only one chef to cook Chinese food.

Now the restaurant owner wants to start Mexican, Italian Foods to be available in his restaurant.

To start this owner needs Mexican food cooked by Mexican Chef, Italian food cooked by Italian Chef but to save costs of all owner wants Chinese chef to cook Mexican and Italian Food.

Abstract Factory pattern provided a way to encapsulate a group of individual factories.

Implementation

We will solve the problem for owners of multi-cuisine restaurant by implementing Abstract Factory Pattern.

Illustration of Abstract Factory Pattern
Illustration of Abstract Factory Pattern
Step 1: Abstract Factory Design Pattern Super Classes and Sub Classes

To implement, We need to create basic classes and subclasses for food operations.

Step 2: Factory Class for Each subclass

First of all we need to create an Abstract Factory interface or an abstract class.

Notice that getChineseFood(), getMexicanFood() and getItalianFood() method is returning an instance of super class ChineseFood, MexicanFood and ItalianFood respectively. Now our factory classes will implement this interface and return their respective sub-class.

Lets write a client test method and see how to use the abstract factory to get the instance of sub-classes.

Output :
Chinese Food Order for ChefA Chinese Noodels with Red Sauce ordered Mexican Food Order for ChefB Mexican Nachos Crispy ordered ChineItalianse Food Order for ChefA Italian Pasta with White Sauce ordered Chinese Food Order for ChefB Chinese Rice Spicy ordered
Advantages of Abstract Factory Pattern
  1. It isolates the creation of objects from the client that needs them, giving the client only the possibility of accessing them through an interface, which makes the manipulation easier.

  2. It provides an approach to code for interface rather than implementation.

  3. Abstract Factory pattern is robust and avoid conditional logic of the Factory pattern.

  4. It promotes consistency between products. It is the concrete factory’s job to make sure that the right products are used together.

Drawbacks of Abstract Factory Pattern

Adding a new product requires extending the abstract interface which implies that all of its derived concrete classes also must change.

It's good to share...Share on FacebookTweet about this on TwitterShare on LinkedInPin on PinterestShare on Google+Email this to someone

4 Thoughts on “Abstract Factory Design Pattern in Java”

  • I provided feedback on your LinkedIn article. This is not really a good illustration for an Abstract Factory.

    You example only creates chefs or cooks. That problem is resolved by the Factory Pattern. The reason behind the Abstract Factory is to create objects that are not alike to perform a function. Even though your cooks specialize in different type of foods, the activity performed is the same: cook. In order to take advantage of an Abstract Factory, you need to provide different types of objects to a client.

    To follow your illustration, restaurants have a dine in area and a bar (typically). Therefore, your Abstract Factory should provide either cooks (chefs) or bartenders depending on what the customer wants. If he wants to sit at the bar, the abstract factory provides a bartender. If the customer sits in the dine in area, your abstract factory provides a chef (one of the three). Depending on the order, your ChefFactory should create a Mexican Food Chef, Italian Food Chef, or a Chinese Food Chef.

    If you want to get fancy, you can have your BartenderFactory create different types of bartenders. For example, one that specializes in wines, another that specializes in craft beers, and another on mixed drinks.

    If you do this, you will have a true Abstract Factory example. The one shown here, as is, it is not a good use or illustration of an Abstract Factory.

    • Hi Hector,

      Thanks for reading and providing response. Really appreciate!!

      In our given example our purpose is same which you want to convey. Here cooks or chefs are specialized in their but they are also providing different types of foods. You are asking for two different context to provide in example i.e. Chef and Bartender. But here we have took only one Chef with different cooking example.

      At last we both want to convey the same to readers but with different illustration.

      Thanks
      Team codeNuclear

      • I know what you’re trying to convey. The problem is that Abstract Factory has nothing to do with the result of the methods. Abstract Factory is to solve the problem when you need different OBJECT TYPES created at runtime. What you’re illustrating can be solved with a simple Factory pattern.

        The link I provided you with in the LinkedIn article illustrates a complete example of this. Think about the classic “Animal” class example. By simple polymorphism, you can solve the problem of the “makeSound()” function when a dog barks and a cat meows. This is not a problem solved with an Abstract Factory. The creation of an “Animal” object is solved with a Factory. That said, if you have a “Piano” class that could also “makeSound()” you could then use the Abstract Factory to create distinct objects.

        The bottom line is that your example as is in this article is not an example of the Abstract Factory. In fact, your Class Diagram doesn’t even show the factories. Compare your example to this one: https://www.tutorialspoint.com/design_pattern/abstract_factory_pattern.htm and you will see your’re not following the recipe for this design pattern.

Leave a Reply

Your email address will not be published. Required fields are marked *