Question

I recently came upon an instance of the following pattern:

public interface IFooFactory {
    <K> Foo<K> create();
}

See here for a concrete example. I don’t see what a client programmer is supposed to do in the implementation of create other than instantiate Foo with a formal type parameter of Object or with no formal type parameter at all. I also don’t see what’s the benefit or type constraint that the framework designer tried to express by defining the interface IFooFactory in this way.

Answer 1

Consider Collections.emptyList(). The list object returned is always the same: since the list is empty and immutable, there is nothing the caller can do with the object returned in order to make it show different behaviour depending on the concrete type substituted for the type parameter. So, a single implementation (with raw types) suffices:

public static <T> List<T> emptyList() {
    return THEEMPTYLIST;
}

public static final List THEEMPTYLIST = new List() {
    public int size() { return 0; }
    ...
};

The emptyList method makes this more convenient for the caller, though, since it enables type inference:

List<String> noStrings = Collections.EMPTY;  // Gives compiler warning due to use of raw types
List<String> noStrings2 = Collections.emptyList(); // No compiler warning, type parameter inferred.