Factory Pattern in Java Explained — Real-World Usage and Design

// This is what we're TRYING TO AVOID — tight coupling via direct instantiation.
// Imagine this pattern repeated across 10 service classes.

public class CheckoutService {

    public void processPayment(String paymentType, double amount) {

        // BAD: CheckoutService is tightly coupled to concrete classes.
        // Adding a new payment type means editing THIS method — and every
        // other class that does the same thing.
        if (paymentType.equals("CREDIT_CARD")) {
            CreditCardProcessor processor = new CreditCardProcessor(); // hard dependency
            processor.charge(amount);
        } else if (paymentType.equals("PAYPAL")) {
            PayPalProcessor processor = new PayPalProcessor();         // another hard dependency
            processor.charge(amount);
        }
        // Adding CRYPTO means editing this method. And the one in RefundService.
        // And the one in SubscriptionService. Painful.
    }
}

// The concrete classes we're leaking knowledge about:
class CreditCardProcessor {
    public void charge(double amount) {
        System.out.println("Charging $" + amount + " to credit card.");
    }
}

class PayPalProcessor {
    public void charge(double amount) {
        System.out.println("Charging $" + amount + " via PayPal.");
    }
}

// ─── Step 1: Define the Product Interface ───────────────────────────────────
// All payment processors must implement this contract.
// The factory will always return this type — callers never see the concrete class.
public interface PaymentProcessor {
    void charge(double amount);
    void refund(double amount);
}


// ─── Step 2: Concrete Implementations ───────────────────────────────────────

class CreditCardProcessor implements PaymentProcessor {
    @Override
    public void charge(double amount) {
        // Real impl would call a payment gateway SDK here
        System.out.println("[CreditCard] Charging $" + amount + " via Stripe gateway.");
    }

    @Override
    public void refund(double amount) {
        System.out.println("[CreditCard] Refunding $" + amount + " to card.");
    }
}

class PayPalProcessor implements PaymentProcessor {
    @Override
    public void charge(double amount) {
        System.out.println("[PayPal] Charging $" + amount + " via PayPal REST API.");
    }

    @Override
    public void refund(double amount) {
        System.out.println("[PayPal] Refunding $" + amount + " to PayPal account.");
    }
}

class CryptoProcessor implements PaymentProcessor {
    @Override
    public void charge(double amount) {
        System.out.println("[Crypto] Charging $" + amount + " worth of BTC on-chain.");
    }

    @Override
    public void refund(double amount) {
        // Crypto refunds are a manual process in reality
        System.out.println("[Crypto] Initiating manual refund of $" + amount + ".");
    }
}


// ─── Step 3: The Factory ─────────────────────────────────────────────────────
// This is the ONLY place that knows about concrete classes.
// To add a new payment type: add it here. Nothing else changes.

class PaymentProcessorFactory {

    // Using an enum as the key is safer than raw Strings — typos become
    // compile errors instead of silent runtime failures.
    public enum PaymentType {
        CREDIT_CARD, PAYPAL, CRYPTO
    }

    public static PaymentProcessor create(PaymentType type) {
        // Switch expression (Java 14+) — clean, exhaustive, no fall-through bugs
        return switch (type) {
            case CREDIT_CARD -> new CreditCardProcessor(); // factory decides the concrete type
            case PAYPAL      -> new PayPalProcessor();
            case CRYPTO      -> new CryptoProcessor();
            // No default needed — enum exhaustiveness is checked at compile time
        };
    }
}


// ─── Step 4: The Client (CheckoutService) ───────────────────────────────────
// Notice: CheckoutService imports ZERO concrete processor classes.
// It only knows about PaymentProcessor (the interface) and PaymentProcessorFactory.

class CheckoutService {
    private final PaymentProcessorFactory.PaymentType preferredPaymentType;

    public CheckoutService(PaymentProcessorFactory.PaymentType preferredPaymentType) {
        this.preferredPaymentType = preferredPaymentType;
    }

    public void completePurchase(double orderTotal) {
        // Ask the factory for the right processor — we don't care which class comes back
        PaymentProcessor processor = PaymentProcessorFactory.create(preferredPaymentType);

        processor.charge(orderTotal);  // polymorphic call — works for any implementation
        System.out.println("Purchase complete. Total charged: $" + orderTotal);
    }
}


// ─── Step 5: Main — wire it together and run ─────────────────────────────────
class Main {
    public static void main(String[] args) {
        // Simulate three different customers with different payment preferences
        CheckoutService cardCustomer   = new CheckoutService(PaymentProcessorFactory.PaymentType.CREDIT_CARD);
        CheckoutService paypalCustomer = new CheckoutService(PaymentProcessorFactory.PaymentType.PAYPAL);
        CheckoutService cryptoCustomer = new CheckoutService(PaymentProcessorFactory.PaymentType.CRYPTO);

        cardCustomer.completePurchase(49.99);
        paypalCustomer.completePurchase(149.00);
        cryptoCustomer.completePurchase(999.00);
    }
}

// ─── Product Interfaces ──────────────────────────────────────────────────────
// Each UI component type gets its own interface.

interface Button {
    void render();
    void onClick();
}

interface Dialog {
    void show(String message);
}


// ─── Windows Concrete Products ───────────────────────────────────────────────

class WindowsButton implements Button {
    @Override
    public void render() {
        System.out.println("[Windows] Rendering a flat, square button with ClearType font.");
    }
    @Override
    public void onClick() {
        System.out.println("[Windows] Playing Windows click sound effect.");
    }
}

class WindowsDialog implements Dialog {
    @Override
    public void show(String message) {
        System.out.println("[Windows] Modal dialog box: " + message);
    }
}


// ─── Mac Concrete Products ───────────────────────────────────────────────────

class MacButton implements Button {
    @Override
    public void render() {
        System.out.println("[Mac] Rendering a rounded, glossy button with SF Pro font.");
    }
    @Override
    public void onClick() {
        System.out.println("[Mac] Playing macOS click haptic feedback.");
    }
}

class MacDialog implements Dialog {
    @Override
    public void show(String message) {
        System.out.println("[Mac] HUD-style dialog sheet: " + message);
    }
}


// ─── Abstract Factory Interface ──────────────────────────────────────────────
// This is the core of the Abstract Factory pattern.
// It declares a creation method for EACH product in the family.

interface UIComponentFactory {
    Button createButton();
    Dialog createDialog();
    // If we add TextField later, we add createTextField() here
    // and implement it in ALL concrete factories — compiler enforces completeness.
}


// ─── Concrete Factories ──────────────────────────────────────────────────────
// Each factory produces a CONSISTENT family of components.
// You can't accidentally mix Mac buttons with Windows dialogs.

class WindowsUIFactory implements UIComponentFactory {
    @Override
    public Button createButton() {
        return new WindowsButton(); // guaranteed Windows-themed
    }
    @Override
    public Dialog createDialog() {
        return new WindowsDialog(); // guaranteed Windows-themed
    }
}

class MacUIFactory implements UIComponentFactory {
    @Override
    public Button createButton() {
        return new MacButton(); // guaranteed Mac-themed
    }
    @Override
    public Dialog createDialog() {
        return new MacDialog(); // guaranteed Mac-themed
    }
}


// ─── Application — only depends on the abstract factory interface ─────────────

class Application {
    private final Button confirmButton;
    private final Dialog errorDialog;

    // The factory is injected — Application has ZERO knowledge of Windows vs Mac.
    // Swap the factory, and every component produced automatically changes theme.
    public Application(UIComponentFactory factory) {
        this.confirmButton = factory.createButton();
        this.errorDialog   = factory.createDialog();
    }

    public void run() {
        confirmButton.render();
        confirmButton.onClick();
        errorDialog.show("File not found — please check the path and try again.");
    }
}


// ─── Main ────────────────────────────────────────────────────────────────────

class UIMain {
    public static void main(String[] args) {
        String operatingSystem = System.getProperty("os.name").toLowerCase();

        // Decide which factory to use ONCE — at the entry point of the app.
        // Everything downstream gets consistent components automatically.
        UIComponentFactory factory;
        if (operatingSystem.contains("mac")) {
            factory = new MacUIFactory();
        } else {
            factory = new WindowsUIFactory();
        }

        Application app = new Application(factory);
        app.run();
    }
}

import java.text.NumberFormat;
import java.util.Calendar;
import java.util.List;
import java.util.Locale;
import java.util.Set;

public class FactoryPatternInJavaSDK {

    public static void main(String[] args) {

        // ── Calendar.getInstance() ───────────────────────────────────────────
        // Returns a BuddhistCalendar in Thailand, a JapaneseImperialCalendar in Japan,
        // a GregorianCalendar everywhere else. You don't pick — the factory picks.
        Calendar today = Calendar.getInstance(); // factory method — returns correct subclass
        System.out.println("Today's year: " + today.get(Calendar.YEAR));
        System.out.println("Calendar impl class: " + today.getClass().getSimpleName());

        // ── NumberFormat factory methods ─────────────────────────────────────
        // Same interface, radically different formatting behaviour by locale.
        // You never call `new SomeCurrencyFormat()` — the factory handles it.
        NumberFormat usDollarFormat   = NumberFormat.getCurrencyInstance(Locale.US);
        NumberFormat euroFormat       = NumberFormat.getCurrencyInstance(Locale.GERMANY);
        NumberFormat japanYenFormat   = NumberFormat.getCurrencyInstance(Locale.JAPAN);

        double price = 1299.99;
        System.out.println("US:      " + usDollarFormat.format(price));  // factory-produced formatter
        System.out.println("Germany: " + euroFormat.format(price));      // different impl, same interface
        System.out.println("Japan:   " + japanYenFormat.format(price));  // yet another impl

        // ── Collections factory methods (Java 9+) ────────────────────────────
        // List.of() and Set.of() return private internal implementations
        // (ImmutableCollections$List12, etc.) — you never see or care about the
        // concrete class. Classic factory pattern: ask for a List, get an optimised impl.
        List<String> paymentMethods = List.of("CREDIT_CARD", "PAYPAL", "CRYPTO");
        Set<String>  currencies     = Set.of("USD", "EUR", "JPY", "BTC");

        System.out.println("Payment methods: " + paymentMethods);
        System.out.println("List impl class: " + paymentMethods.getClass().getName()); // not java.util.ArrayList!
        System.out.println("Currencies: " + currencies);
    }
}