Understanding the Abstract Factory Pattern: Theory, Real‑World Scenarios, and Java Code

What Is the Abstract Factory Pattern?

In plain terms, the Factory Method can produce a single type of product, whereas the Abstract Factory can produce an entire set of related products, ensuring a consistent style across the product family without invoking multiple factories.

The core purpose is to constrain products to match as a set, unify product families, and reduce scattered creation logic.

Real‑World Scenarios

Mobile accessory bundles: an Apple factory produces Apple phones and Apple chargers; an Android factory produces Android phones and Android chargers, and the accessories cannot be mixed.

Software UI themes: light and dark themes each include a matching set of buttons, dialogs, and input fields.

Payment suites: WeChat Pay includes a payment gateway, refund service, and reconciliation tools; Alipay provides its own matching components.

Java Implementation

1. Abstract Products

// Product 1: Phone abstract interface
public interface Phone {
    void showPhone();
}

// Product 2: Charger abstract interface
public interface Charger {
    void showCharger();
}

2. Concrete Products (Apple series)

public class IPhone implements Phone {
    @Override
    public void showPhone() {
        System.out.println("苹果手机");
    }
}

public class IPhoneCharger implements Charger {
    @Override
    public void showCharger() {
        System.out.println("苹果充电器");
    }
}

3. Concrete Products (Android series)

public class AndroidPhone implements Phone {
    @Override
    public void showPhone() {
        System.out.println("安卓手机");
    }
}

public class AndroidCharger implements Charger {
    @Override
    public void showCharger() {
        System.out.println("安卓充电器");
    }
}

4. Abstract Factory Interface

public interface ProductFactory {
    Phone createPhone();
    Charger createCharger();
}

5. Concrete Factories

// Apple family factory
public class AppleFactory implements ProductFactory {
    @Override
    public Phone createPhone() {
        return new IPhone();
    }
    @Override
    public Charger createCharger() {
        return new IPhoneCharger();
    }
}

// Android family factory
public class AndroidFactory implements ProductFactory {
    @Override
    public Phone createPhone() {
        return new AndroidPhone();
    }
    @Override
    public Charger createCharger() {
        return new AndroidCharger();
    }
}

6. Test Client

public class Test {
    public static void main(String[] args) {
        // Apple full set
        ProductFactory apple = new AppleFactory();
        apple.createPhone().showPhone();
        apple.createCharger().showCharger();

        // Android full set
        ProductFactory android = new AndroidFactory();
        android.createPhone().showPhone();
        android.createCharger().showCharger();
    }
}

Typical Business Use Cases

Multiple groups of complementary products that must be used together.

Cross‑platform UI components: separate sets of dialogs, forms, and buttons for PC and mobile.

Multi‑channel payment processing: each channel (WeChat, Alipay) has its own payment, refund, and reconciliation tools.

Multi‑database adapters: MySQL and Oracle each require their own connection, query, and transaction utilities.

Skin/theme switching: a full suite of UI components changes uniformly.

Drawbacks

Adding a new single product requires modifying the top‑level abstract factory, which incurs high change cost; therefore the pattern is best suited for projects where product families remain stable.

Conclusion

This concludes the third installment on the Abstract Factory pattern; the next article will cover the Builder pattern.