Samstag, 15. Dezember 2007

Instantiating Generic Type Parameters with Factory Pattern

Some weeks ago a cowoker of mine asked me for help. He wanted to write a class with generic parameter type and create a new object of this generic type inside the class. I.E. he wanted to write something like this in Java:


public class WrongSyntax<T> {
public void someMethod() {
T object = new T(); //this line does not compile
}
}
There are some reasons why this code can't compile. Most evident reason is that T could be an interface and you can't instantiate an interface. And you have to be aware generics are boiling down to one rule : Generics are a double-check on compile time but at runtime the type parameter will be replaced by java.lang.Object and casts to the parameter type. This effect is called type erasure.

If you use java.lang.String as parameter type (and the compiler would not reject the marked line) this class would be replaced by:

public class WrongSyntax<T> {
public void someMethod() {
String object = (String) new Object();
}
}

You would get a ClassCastExcetion on runtime, therefore the compiler does not allow it.

Some days ago I read an article by Angelika Langer & Klaus Kreft regarding this problem in the German Java SPEKTRUM magazin. I'm afraid you won't find it online but there is an excellent english FAQ about Java Generics on Langer's site.

In this said article they discuss the problem of array and simple type instantiation for type parameters. Even though they brought up several solutions for arrays they came up with only one for simple types: Using reflection.


public class UsingReflection<T> {

public static <T> void createInstance(Class<T> clazz) {
T instance;
try {
instance = clazz.newInstance(); // does not work for every class
} catch (InstantiationException e) {
//...
} catch (IllegalAccessException e) {
//...
}

//...

}
}


While this will work for some classes it is obvious that it will not work for interfaces, abstract classes and classes without a default constructor.

Here are two examples that will pass the compiler but fail on runtime:



// throws java.lang.InstantiationException
new UsingReflection().createInstance(Serializable.class);

// throws java.lang.IllegalAccessException
new UsingReflection().createInstance(AbstractCollection.class);



To my mind there is a reason why instantiating type parameters is so difficult. In the first place generics are a double-check for programmers to avoid class cast exceptions. But there is more to it. Using generics brings you the benefit of decoupling an algorithm from the type it works on. But if you are trying to create a new instance of this type your generic code isn't indepent from this type anymore.

Fortunately there is a solution to the problem known from one of the most referenced books in software engineering - the GOF-Book. It's called Factory Pattern. And with generics the factory pattern is even more powerful. Your factories only need to implement the generic Factory interface


public interface Factory<T> {

public T create();

}


and your generic algorithm can trustfully rely on it.


public class UsingFactory<T> {

Factory<T> factory; // or maybe use Factory<? extends T> factory;

public UsingFactory(Factory<T> factory) {
this.factory = factory;
}

public void someMethod() {
T instance = factory.create();
//...
}

}


Object creation and object using are now decoupled, while the algorithm and the type it works on are decoupled too.

Now you can even implement a class GenericFactory<T> which uses reflection for instantiation. But you don't have to. You aren't forced to use a class with default constructor for T. But generics still work for you and the compiler will complain if the factory type parameter and the type parameter of your algorithm do not match.


// SimpleString creates Strings just like everybody does
Factory<String> simpleStringFactory = new SimpleStringFactory();

UsingFactory<String> useSimple = new UsingFactory<String>(simpleStringFactory);


// instantiates a factory that creates Strings via reflection
Factory<String> stringFactory = new GenericFactory<String>(String.class);

UsingFactory<String> useString = new UsingFactory<String>(stringFactory); // this works like expected

UsingFactory<Long> useLong = new UsingFactory<Long>(stringFactory); //type params do not match; does not compile

6 Kommentare:

Alex Miller hat gesagt…

You might note that Class now follows this pattern. Class is now Class<T> and is a factory for instances via Class.newInstance().

Richard Metzler hat gesagt…

Thank you for your comment. You are right and I recognized that I had a typo in my post (wrote Class<t> instead of Class<T>).

But you seem to have not read the whole post because I pointed out that it is not good to use Class<T>.newInstance() because there are cases when it fails.

Unknown hat gesagt…

First up, I like your use of the factory pattern: welcome back type safety.

However, in the second code example, the one that uses Class<T> clazz, it is notable that this requires some extra plumbing, i.e., you will need to assign that member in some constructor (since newInstance() is not static, and clazz will be of type Class at runtime anyway).
In the end, this means we will have to pass in the 'real' class, meaning we have a point of failure that will only show up at runtime.

Richard Metzler hat gesagt…

Yes Angelo, that's exactly what I tried to say.

I'll update the examples later.

Thank you for the feedback.

patrick hat gesagt…

The referenced article by Angelika Langer & Klaus Kreft is available online at http://www.angelikalanger.com/Articles/Topics.html#JAVA.

Anonym hat gesagt…

來看看你囉~blog很棒! ...........................................................................

Powered By Blogger