A Closer Look at the Java Generic Factory Pattern

During my last project, I was required to build complex objects based on values derived from an XML File. We decided to use the Builder Pattern to help build complex objects.

For complex objects, which are aggregates of Domain-Driven Design, the building process, in the end, is a long method that builds all parts of the complex object. I was looking for a pattern that would allow me to create different components using only one method.

You may also like: Understanding the Use Cases of Java Generics

The first step was to create a functional interface as an implementation contract for all part factories.

public interface ElementFactory<T> {

  T build(Document document, XPATHHidaValues xpathHidaValues) throws Exception;

}

The return type of the build method is a generic type with the ability to collect different parts of the objects. The parameters document and XPATHHidaValues can be ignored because these objects are only relevant when getting the attribute values from an XML document using XPATH. For your project, you can use whatever you need to create different objects.

The next step was to create a factory registry to get the relevant factory.

public class ElementFactoryRegistry {

  private static Map<Class<?>, ElementFactory<?>> elementBuilder = new HashMap<>();

  static {

    elementBuilder.put(Schreibsprache.class, new SchreibSpracheFactory());
    elementBuilder.put(Material.class, new MaterialListFactory());
    elementBuilder.put(Abmessungen.class, new AbmessungFactory());
    elementBuilder.put(Format.class, new FormatFactory());
    elementBuilder.put(Umfang.class, new UmfangFactory());
    elementBuilder.put(Schrift.class, new SchriftenListFactory());

  }

  public static <T> T buildElement(Type targetType, Document document,
      XPATHHidaValues xpathHidaValues)
      throws Exception {

    if (!elementBuilder.containsKey(targetType)) {

      throw new IllegalArgumentException("Missing Element Factory for Type " + targetType);
    }

    return (T) elementBuilder.get(targetType).build(document, xpathHidaValues);
  }
}

As you can see, the registry object is mainly static. For the registration of all factories, I used a HashMap. The key is the needed target class, which should be created as part of the complex aggregate. The value is the proper element factory class. Both elements of the map are typed using the generic wildcard character.

Additionally, you can see that the build element method checks to see if the factory is registered using a generic cast to build the needed class component. The main advantage of this is that the client doesn’t need any cast and can use the method at different points.

BeschreibungsKomponenteAeusseres aeusseres = new BeschreibungsKomponenteAeusseresBuilder()
    .withId(UUID.randomUUID().toString())
    .withMaterialen(
        buildElement(Material.class, document, xpathHidaValues))
    .withAbmessungen(buildElement(Abmessungen.class, document, xpathHidaValues))
    .withFormat(buildElement(Format.class, document, xpathHidaValues))
    .withUmfang(buildElement(Umfang.class, document, xpathHidaValues))
    .withSchriften(buildElement(Schrift.class, document, xpathHidaValues))
    .build();

Here, you can see the magic happen — you now have the Java generics type system. The client is using the builder pattern and can use the magic factory method buildElement to build the proper object. Based on the target type class, this method selects the proper factory and creates the relevant object type.

 At first, it will create a Material, and the next time, it will create a Format object. From my point of view, the code is very clean and readable so that can every other developer on the team can easily add new factories. 

Further Reading

Java: The Factory Method Pattern

Understanding the Use Cases of Java Generics