Creator pattern

The closest relative of the Creator pattern is the Abstract factory pattern, but the abstract factory pattern does not allow to choose the factory automatically by a context, does not allow for a generalized behavior, does not allow for a fallback behavior, the client needs some knowledge about the concrete factory (implementation) to choose the intended behavior, and that pattern creates a dependency from the client to the concrete factory. Moreover, it has been criticized that the abstract factory pattern creates higher efforts, when new object types are implemented and it has been criticized that it likely creates duplicate code. While this is true for the pure and simple variant of the abstract factory pattern, these issues can be solved by some simple amendments.

A reasoning and comparison with the dependency injection pattern will be discussed in a separate article.

Please note: Since the implementations of creators are just lightweight siblings of the implementations of the related object type, the implementations of creators can be generated from their siblings (e.g. with a template engine). It is strongly recommended to generate the creators as a generalization which shall not be altered by hand (overwritten on each generation) and as a concrete extension of that generalization which can be altered by hand if needed (just generated if missing).

Basic Navigator pattern

The following UML class diagram shows a basic variant of the Creator pattern:

(click on the image)

The following UML sequence diagram shows selected interactions for the basic variant of the Navigator pattern:

(click on the image)

Enhanced Navigator pattern

The following UML class diagram shows an enhanced variant of the Creator pattern, where creators and factories are divided into different domains or subdomains, e.g. modules:

(click on the image)