Day 6: Abstract Factory Pattern

Welcome to the sixth day of my 30-Day Design Pattern Challenge! Today, we’re going to explore the Abstract Factory Pattern, a creational design pattern that provides a way to create families of related objects without specifying the exact classes of the objects that will be created.

What is it?

The Abstract Factory Pattern is a creational design pattern that provides an interface for creating families of related objects without specifying the exact classes of the objects that will be created. It differs from the Factory Method Pattern by introducing a layer of abstraction that allows for the creation of multiple families of products.

Problem

Imagine you’re building a furniture store application that sells different styles of furniture, such as Victorian and Modern. You initially implement classes for Victorian chairs and sofas. As the application evolves, you decide to include Modern furniture as well. Simply adding new furniture classes can cause issues because the rest of the code might be coupled to the existing Victorian furniture classes.

Solution

The Abstract Factory Pattern suggests creating an abstract factory interface that defines methods for creating different product types within a family. Concrete factory classes implement this interface and provide the logic for creating specific furniture pieces (chairs and sofas) for a particular style (Victorian or Modern). This allows you to introduce new furniture styles without modifying the existing code that interacts with the factory.

Class Diagram

The class diagram consists of the following entities:

• Abstract Factory
• Concrete Factory
• Abstract Product (for each product type)
• Concrete Product (for each concrete product)

Class Diagram

Example

public interface FurnitureFactory {
  Chair createChair();
  Sofa createSofa();
}

public class VictorianFurnitureFactory implements FurnitureFactory {
  @Override
  public Chair createChair() {
    return new VictorianChair();
  }
  @Override
  public Sofa createSofa() {
    return new VictorianSofa();
  }
}

public class ModernFurnitureFactory implements FurnitureFactory {
  @Override
  public Chair createChair() {
    return new ModernChair();
  }
  @Override
  public Sofa createSofa() {
    return new ModernSofa();
  }
}

public abstract class Chair {
  // Implement common chair functionality
}

public class VictorianChair extends Chair {
  // Implement Victorian chair specific functionality
}

public class ModernChair extends Chair {
  // Implement Modern chair specific functionality
}

public abstract class Sofa {
  // Implement common sofa functionality
}

public class VictorianSofa extends Sofa {
  // Implement Victorian sofa specific functionality
}

public class ModernSofa extends Sofa {
  // Implement Modern sofa specific functionality
}

public class Client {
  public void orderFurniture(FurnitureFactory factory) {
    Chair chair = factory.createChair();
    Sofa sofa = factory.createSofa();
    
    // Use chair and sofa objects
  }
  public static void main(String[] args) {
    Client client = new Client();
    
    client.orderFurniture(new VictorianFurnitureFactory());
    client.orderFurniture(new ModernFurnitureFactory());
  }
}

Other Examples

• The javax.swing.UIManager class in Java Swing uses an Abstract Factory Pattern to create platform-specific UI components.

Benefits

• Promotes loose coupling between client code and concrete product classes.
• Provides flexibility in creating different product families.
• Makes it easier to add new product families without modifying existing code.

Disadvantages

• Can introduce additional complexity if overused.
• Might require more upfront planning and design effort.

When to Use

• When you need to create families of related objects without specifying the exact classes.
• When you want to decouple client code from concrete product classes.
• When your application needs to support multiple product variations (e.g., different UI themes, database access layers).

When Not to Use

• When the application only deals with a single product family and future expansion is unlikely.
• When the cost of introducing an abstraction layer outweighs the benefits.

Conclusion

That’s it for today’s post on the Abstract Factory Pattern! And Here we’re done creational design pattern. I hope you enjoyed learning about this creational design pattern. Stay tuned for the next post, where we’ll explore our first structural pattern : Adapter Pattern!

Join me on this 30-day journey, and let’s explore the world of design patterns together! If you have any questions or feedback, please leave a comment below. I’d love to hear from you!

If you liked this blog, please clap👏!