Abstract Factory Method and Polymorphism Explained

I guess it depends on how it is used.

Essentially the Factory pattern is a reference to a set of objects. Normally combined with something else, possibly like the Strategy pattern (which is more likely to be defined as a type of polymorphism) to provide reference to an object to act on.

The Abstract Factory Pattern by itself is intended to be polymorphic as it is defined as an abstract class type. However the concrete implementation of the factory is the WidgetFactory in your type and is only polymorphic in reference to using a factory and providing an implementation of a factory.

In terms of what you are after, you certainly require a concrete factory, and presumably the actions you perform depend on the exception being caught. To that end you would use your factory implementation in a non-polymorphic way simply by passing it the exception caught, and have the factory pattern return a method to invoke a strategy or even a chain-of-command pattern to deal with how you would like to handle the exception.

Therefore, your factory would not necessarily be polymorphic, and your exception handlers would be polymorphic.

A factory method is essentially just a constructor with another name. This can be useful e.g. to guarantee correct initialization, registration, or to supply default values without having to subclass the product:

private List<WeakReference<Product>> products = ...;

public Product makeProduct(Param x) {
    Product instance = new Product(x, "default value");
    instance.initialize(42);
    products.add(new WeakReference<>(instance));
    return instance;
}

An abstract factory pattern is usually implemented in terms of factory methods, but here the aim is to leave the concrete type unspecified until runtime. So we have a set of products:

interface Product {}
class ConcreteProduct1 implements Product {}
class ConcreteProduct2 implements Product {}

And we have an abstract factory:

interface Factory {
    public Product makeProduct();
}

Such a factory might be used by client code: factory.makeProduct(). Which concrete product is used is delayed to runtime.

class ConcreteFactory1 implements Factory {
    public Product makeProduct() { return new ConcreteProduct1(); }
}

class ConcreteFactory2 implements Factory {
    public Product makeProduct() { return new ConcreteProduct2(); }
}

Typically, an abstract factory will have multiple factory methods for a set of related types, you can think of a factory instance as a “theme”. Abstract factories are also useful for dependency injection.

The factory method pattern is a combination of factory methods with the strategy pattern. Here the idea is that our class needs to create some instance, but will let subclasses override the choice of the instance. In other words, the client and the factory are the same.

class DomainSpecificStuff {
    public doDomainSpecificStuff() {
        Product p = this.makeProduct();
        p.frobnicate();
    }

    protected makeProduct() {
        return new  ConcreteProduct1();
    }
}

class OtherDomainSpecificStuff {
    @Override
    protected makeProduct() {
        return new ConcreteProduct2();
    }
}

So the strategy pattern allows for limited dependency injection through the use of inheritance when used as the FMP.

So what are the useful distinctions between the factory method pattern and abstract factory pattern?

• Client: The client of the factory method in the FMP is the factory itself – it's just a spin on the strategy pattern, after all. The client of the AFP is some other class.

• Number of Objects: Typically, the FMP will only have a single factory method, whereas the AFP can be used to produce multiple related objects. It is not the case that an AFP must have at least two factory methods, although the creation of related, interdependent objects is where the AFP shines.

• Intent: The AFP is a collection of related factory methods which can be passed around in client code. The FMP allows subclasses to swap out a dependency.