Implementation Issues

Variant 1: Abstract Factory
Creating different families of objects.

• Interface and implementation are cleanly separated.
• This is the way to implement the Abstract Factory pattern for applications that support creating families of related or dependent objects (see Sample Code / Example 1).
• "An application typically needs only one instance of a ConcreteFactory per product family. So it's usually best implemented as a Singleton(127)." [GoF, p90] See Sample Code / Example 3.

Variant 2: Concrete Factory
Creating (a family of) objects.

• Interface and implementation are not cleanly separated.
• The concrete Factory1 class acts as both interface and implementation (it abstracts and implements object creation).
• This is a common way to implement the Abstract Factory pattern for applications that do not need to create families of objects but want to be independent of how their objects are created (see Sample Code / Example 2).
• "Also note that MazeFactory is not an abstract class; thus it acts as both the AbstractFactory and the ConcreteFactory. This is another common implemen­tation for simple applications of the Abstract Factory pattern." [GoF, p94]
• "Notice that the [concrete] MazeFactory is just a collection of factory methods. This is the most common way to implement the Abstract Factory pattern." [GoF, p94]