# Factory Method vs Abstract Factory Pattern in Java: When to Use Each

> Learn when to use Java's Factory Method vs Abstract Factory patterns. Delegate product creation to subclasses with Factory Method or build families of related objects with Abstract Factory.

- Repository: [Ilkka Seppälä/java-design-patterns](https://github.com/iluwatar/java-design-patterns)
- Tags: comparison
- Published: 2026-02-27

---

**Use Factory Method when you need to delegate instantiation of a single product type to subclasses, and use Abstract Factory when you need to create families of related objects that must be used together.**

Choosing between Factory Method and Abstract Factory is a common design decision in Java applications. Both patterns, implemented in the iluwatar/java-design-patterns repository, decouple object creation from client code but solve different architectural problems. Understanding when to apply each pattern ensures your codebase remains maintainable and extensible.

## Understanding the Core Difference

The **Factory Method** pattern defines an interface for creating a single object but lets subclasses decide which class to instantiate. In contrast, the **Abstract Factory** pattern provides an interface for creating families of related or dependent objects without specifying their concrete classes.

## When to Use Factory Method Pattern in Java

### Single Product Hierarchy with Subclass Variations

Use Factory Method when you have one product interface but multiple implementations, and you want concrete creator subclasses to handle instantiation logic. In the java-design-patterns repository, the `Blacksmith` interface defines the factory method `manufactureWeapon`, while `OrcBlacksmith` and `ElfBlacksmith` provide specific implementations.

```java
// Client code from App.main
Blacksmith blacksmith = new OrcBlacksmith();
Weapon weapon = blacksmith.manufactureWeapon(WeaponType.SPEAR);

```

The `OrcBlacksmith` class encapsulates creation logic in `manufactureWeapon`, referencing an internal `ORCARSENAL` map to return appropriate `OrcWeapon` instances based on the `WeaponType` enum. This approach isolates weapon creation details from the client, allowing the blacksmith type to determine the specific weapon implementation.

Key files in the Factory Method implementation:
- [`Blacksmith.java`](https://github.com/iluwatar/java-design-patterns/blob/main/Blacksmith.java) – Defines the factory method interface
- [`OrcBlacksmith.java`](https://github.com/iluwatar/java-design-patterns/blob/main/OrcBlacksmith.java) – Concrete creator with cached weapon instances
- [`ElfBlacksmith.java`](https://github.com/iluwatar/java-design-patterns/blob/main/ElfBlacksmith.java) – Alternative concrete creator
- [`WeaponType.java`](https://github.com/iluwatar/java-design-patterns/blob/main/WeaponType.java) – Enum parameter for the factory method

## When to Use Abstract Factory Pattern in Java

### Families of Related Products

Choose Abstract Factory when your system requires creating sets of related objects that must be used together consistently. The pattern ensures that a family of products (such as `Castle`, `King`, and `Army`) are all of the same variant (Orc or Elf).

In the repository, `KingdomFactory` declares methods for creating each product in the family:

```java
public interface KingdomFactory {
    Castle createCastle();
    King createKing();
    Army createArmy();
}

```

Concrete implementations like `OrcKingdomFactory` and `ElfKingdomFactory` produce complete, compatible families. The `OrcKingdomFactory` creates `OrcCastle`, `OrcKing`, and `OrcArmy`, ensuring no mixing of Elf and Orc components.

### Runtime Family Selection

Abstract Factory excels when the client must switch between product families at runtime without code modification. The `App` class demonstrates this by using `Kingdom.FactoryMaker.makeFactory` to select the factory type dynamically:

```java
// Runtime selection of factory family
KingdomFactory factory = Kingdom.FactoryMaker.makeFactory(Kingdom.FactoryMaker.KingdomType.ELF);
createKingdom(factory);

```

This approach decouples the client from concrete class names, allowing new kingdom types to be added without modifying existing client code.

Key files in the Abstract Factory implementation:
- [`KingdomFactory.java`](https://github.com/iluwatar/java-design-patterns/blob/main/KingdomFactory.java) – Abstract factory interface defining the product family
- [`OrcKingdomFactory.java`](https://github.com/iluwatar/java-design-patterns/blob/main/OrcKingdomFactory.java) – Concrete factory for Orc-themed objects
- [`ElfKingdomFactory.java`](https://github.com/iluwatar/java-design-patterns/blob/main/ElfKingdomFactory.java) – Concrete factory for Elf-themed objects
- [`App.java`](https://github.com/iluwatar/java-design-patterns/blob/main/App.java) – Client demonstrating runtime factory selection

## Side-by-Side Comparison

| Aspect | Factory Method | Abstract Factory |
|--------|---------------|------------------|
| **Scope** | Single product type | Family of related products |
| **Implementation** | Abstract method in creator class | Interface with multiple factory methods |
| **Client Knowledge** | Knows abstract creator, not concrete products | Knows abstract factory, not concrete families |
| **Extensibility** | Add new products via new creator subclasses | Add new families via new factory implementations |
| **Runtime Switching** | Possible but less natural | Designed for runtime family selection |

## Summary

- Use **Factory Method** when you need to create a single product type and want subclasses to determine the concrete implementation, as seen in the `Blacksmith` hierarchy manufacturing individual weapons.
- Use **Abstract Factory** when you need to create families of related objects that must remain consistent, such as the `KingdomFactory` producing matching castles, kings, and armies.
- Both patterns decouple client code from concrete classes, but Abstract Factory adds the constraint of family compatibility while Factory Method focuses on single product instantiation.

## Frequently Asked Questions

### Can Factory Method and Abstract Factory be used together?

Yes, these patterns often complement each other. An Abstract Factory implementation might use Factory Methods internally to create individual products within the family. For example, a concrete kingdom factory could delegate weapon creation to a blacksmith's factory method while coordinating the overall family creation.

### Which pattern is better for dependency injection frameworks?

Abstract Factory aligns well with dependency injection when you need to inject entire configurations or themes into an application. Factory Method is more suitable when you need to inject specific creation strategies for individual components. Modern frameworks like Spring can handle both patterns through `@Bean` methods or `FactoryBean` interfaces.

### How do I decide between Factory Method and Abstract Factory?

Analyze your product structure. If you have only one product interface with multiple implementations and the variation depends on the creator type, choose Factory Method. If you have multiple product interfaces that must be created together as a consistent set, choose Abstract Factory. The java-design-patterns repository demonstrates this distinction clearly through the `Blacksmith` (single product) and `KingdomFactory` (product family) examples.

### Are these patterns still relevant in modern Java?

Absolutely. Despite the introduction of functional interfaces and lambda expressions in Java 8+, both patterns remain essential for complex object creation scenarios. Factory Method provides a clean way to override creation in inheritance hierarchies, while Abstract Factory ensures type safety across product families. The patterns are particularly valuable in library design and when working with legacy codebases that require consistent object creation strategies.