Clarifying UML class diagram of Factory Method design pattern

Question

I was learning factory method design pattern and found following class diagram in a tutorial. I understand product and concreteProduct part but Creator and ConcreteCreator part look little vague to me. I appreciate if someone clarifies the UML diagram. Thanks.

Answer 1

The Factory Method pattern describes a way to encapsulate and delegate instantiation of a type. The factory method is usually prefixed with Create... e.g. Creator.CreateSpecializedObject() and defined abstract.

The purpose of this pattern is to delegate instantiation and initialization of the consumed object instance from the caller or consumer (the superclass or base class) away to a more specialized subclass.

Since the factory method is supposed to return the abstract type of the produced instance, the consumer e.g. superclass/base class can create and consume instances of the produced type in advance and without knowing the concrete implementation. The consumer only operates on abstractions.

Factory Method allows to implement a default behavior for a type that requires to operate on instances of an abstract type. The specialized implementations of this abstract type are then provided by the inheritors, which have to override/implement the abstract factory method to return this type.

Scroll down to see a brief example of this pattern...

---

In UML model language, class members like fields are called Attribute and methods are called Operation. In UML, everything has a meaning e.g., symbols, stroke style of lines, arrow design and font formatting like italic letters.

The diagram says:

a) We have an abstract type Product.
We know it is abstract, because the class name is written in italic letters.

b) There is a concrete class ConcreteProduct.
We know it is concrete i.e. an implementation, because the class name is written in normal letters.

c) The arrow that points from ConcreteProduct to Product describes that ConcreteProduct inherits Product (Generalization).
We know it, because a hollow arrow always symbolizes inheritance and always points from the subclass (inheriting type) to the superclass (base type, the generalization of the subclass).

This arrow expresses: "{type_B} is subclass of {type_A}"
or "{type_B} ? {type_A}".

When the abstract type would be an interface, you would've replaced the arrow with a dashed hollow arrow (with the same orientation).

The relationship between a class ClassA and interface is called Realization.
The relationship between a class ClassA and its parent class (superclass) is called Generalization.

d) Then we have another abstract class Creator, that declares the public operation (method) FactoryMethod() and another public operation AnOperation() as a contract, that every non-abstract inheritor must implement.
We know both methods are public because of the prefix +, which symbolizes public visibility (for both attributes and operations).

e) According to the attached arrow we can tell that theConcreteCreator inherits from Creator and therefore is required to implement the in the contract Creator declared public or virtual attributes and operations.

f) Further more the ConcreteCreator has a dependency to the type ConcreteProduct, because it instantiates and returns this type. We know it is a dependency because dependencies are symbolized by the dashed solid arrow. This arrow always points from the depending object to the object it depends on.

It expresses "{type_X} needs/knows/uses {type_Y}"
or "{type_X} ? {type_Y}".

g) The two boxes that look like paper sheets are used to annotate the elements of the diagram. In this case it informs about the return value of the operation.

Alternatively (and preferably) you would add the return value to the signature definition using the colon :. The colon introduces the type of return value, which would be void in case the operation returns nothing.
The following signature describes an operation that takes no argument and returns an instance of type Product: +FactoryMethod(void):Product

The visibility of virtual attributes or methods is identified by their member name being written in italic letters, while other access modifiers (visibilities) are identified by a symbol that precedes the name of the attribute or operation (+: public, -: private, #: protected, ~: internal or package).

---

You cannot create instances of abstract types (abstract classes and interfaces), only of concrete types. If the inheritor of an abstract type is not abstract itself, it must provide an implementation of all members that are not declared as virtual or private.

Abstract types are a contract or a guarantee, that all inheritors (either abstract or concrete implementations) will have the members defined in that contract. Therefore you know that every type that inherits from Creator e.g., ConcreteCreator must have a method FactoryMethod() implemented.

In advanced programming, you only use abstract types as member type declaration. Instead of creating a local, instance or class member or parameter field using the derived type e.g. ConcreteCreator, you use the least specialized superclass or interface that offers the required functionality e.g. Creator. You typically use it like this:

// Instead of: 
// ConcreteCreator concreteCreator = new ConcreteCreator();
Creator creator = new ConcreteCreator();

// Because 'Creator' defines a contract, 
// we know we can always invoke a method called 'FactoryMethod()' 
// on every type that inherits from 'Creator'
// and that the return value is guaranteed 
// to be an instance of type 'Product'
Product product = creator.FactoryMethod();

The implemented factory method ConcreteCreator.FactoryMethod() returns a ConcreteProduct to satisfy the contract defined by the abstract Creator type. This contract defines a return value of type Product. ConcreteProduct is assignable to Product because 'ConcreteProduct' inherits Product.

Factory Method Example

// Abstract creator.
// This abstract class provides a default behavior 
// to pickup and transport persons using a vehicle.
// The actual transportation vehicle is 
// created by the inheritor.
abstract class Driver
{
  // The abstract factory methodthat the inheritor has to implement.
  protected abstract Vehicle CreateVehicle();

  protected List<Persons> PickUpPersons(List<Destination> destinations)
  {    
    List<Person> result = new List<Person>();

    Vehicle vehicle = CreateVehicle();
    foreach (Destination destination in destinations)
    {
      Location location = vehicle.Move(destination);
      Person pickedUpPerson = location.GetPerson();
      result.Add(pickedUpPerson);
    }
    return result;
  }
}

// Concrete creator
class BusDriver extends Driver
{
  protected override Vehicle CreateVehicle()
  {
    // Bus implements Vehicle    
    Vehicle bus = new Bus();
    bus.Refuel(new Diesel(100));
    return bus;
  }

  public decimal StartJob()
  {
    List<Destination> destinations = GetBusStations();
    List<Person> persons = PickUpPersons(destinations);
    decimal pay = CollectMoney(persons);
    return pay;
  }
}

// Concrete creator
class TaxiDriver extends Driver
{
  protected override Vehicle CreateVehicle()
  {
    // Taxi implements Vehicle 
    Vehicle taxi = new Taxi();
    bus.Refuel(new Gasoline(50));
    Clean(taxi);
    return taxi;
  }

  public decimal StartJob()
  {
    List<Destination> destinations = AwaitCaller();
    List<Person> persons = PickUpPersons(destinations);
    decimal pay = CollectMoney(persons);
    return pay;
  }
}

Usage

class TransportationCompany
{
  public void RunBusiness()
  {
    BusDriver = busDriver = new BusDriver();
    decimal cash = busDriver.StartJob();

    TaxiDriver taxiDriver = new TaxiDriver();
    decimal moreCash = taxiDriver.StartJob();
  }
}

Remarks

There is another version of the Factory Method pattern, that uses a static factory method defined in the class itself to create instances of this class:

class ConcreteProduct : Product
{
  public static Product Create()
  {
    Product newProduct = new ConcreteProduct();
    
    // Initialize or configure the new instance
    
    // Return the configured instance
    return newProduct
  }
}

Usage

class Program
{
  public static Main()
  {
    Product product = ConcreteProduct.Create();
  }
}

Answer 2

There is not a Factory Design pattern (in GoF's book). The diagram you included is close to Factory Method. Method is an essential part of the name and cannot be omitted.

The diagram you included looks like a reproduce of the class diagram from the GoF's book. Unfortunately, your reproduce missed some critical points. Below is the diagram from GoF's book.

Factory Method pattern is a special case of Template Method (or at least as shown in the above class diagram^).

I often find it easier to understand if we put it in a sequence diagram:

^ Factory Method does not have to be used with in a Template Method. Abstract Factory is another example that uses Factory Method.