Consider this example (typical in OOP books):
I have an Animal
class, where each Animal
can have many friends.
And subclasses like
Based on the same idea as Super Type Tokens, you could create a typed id to use instead of a string:
public abstract class TypedID<T extends Animal> {
public final Type type;
public final String id;
protected TypedID(String id) {
this.id = id;
Type superclass = getClass().getGenericSuperclass();
if (superclass instanceof Class) {
throw new RuntimeException("Missing type parameter.");
}
this.type = ((ParameterizedType) superclass).getActualTypeArguments()[0];
}
}
But I think this may defeat the purpose, since you now need to create new id objects for each string and hold on to them (or reconstruct them with the correct type information).
Mouse jerry = new Mouse();
TypedID<Dog> spike = new TypedID<Dog>("spike") {};
TypedID<Duck> quacker = new TypedID<Duck>("quacker") {};
jerry.addFriend(spike, new Dog());
jerry.addFriend(quacker, new Duck());
But you can now use the class in the way you originally wanted, without the casts.
jerry.callFriend(spike).bark();
jerry.callFriend(quacker).quack();
This is just hiding the type parameter inside the id, although it does mean you can retrieve the type from the identifier later if you wish.
You'd need to implement the comparison and hashing methods of TypedID too if you want to be able to compare two identical instances of an id.
No. The compiler can't know what type jerry.callFriend("spike")
would return. Also, your implementation just hides the cast in the method without any additional type safety. Consider this:
jerry.addFriend("quaker", new Duck());
jerry.callFriend("quaker", /* unused */ new Dog()); // dies with illegal cast
In this specific case, creating an abstract talk()
method and overriding it appropriately in the subclasses would serve you much better:
Mouse jerry = new Mouse();
jerry.addFriend("spike", new Dog());
jerry.addFriend("quacker", new Duck());
jerry.callFriend("spike").talk();
jerry.callFriend("quacker").talk();
There is another approach, you can narrow the return type when you override a method. In each subclass you would have to override callFriend to return that subclass. The cost would be the multiple declarations of callFriend, but you could isolate the common parts to a method called internally. This seems a lot simpler to me than the solutions mentioned above, and does not need an extra argument to determine the return type.
what about
public class Animal {
private Map<String,<T extends Animal>> friends = new HashMap<String,<T extends Animal>>();
public <T extends Animal> void addFriend(String name, T animal){
friends.put(name,animal);
}
public <T extends Animal> T callFriend(String name){
return friends.get(name);
}
}
I did the following in my lib kontraktor:
public class Actor<SELF extends Actor> {
public SELF self() { return (SELF)_self; }
}
subclassing:
public class MyHttpAppSession extends Actor<MyHttpAppSession> {
...
}
at least this works inside the current class and when having a strong typed reference. Multiple inheritance works, but gets really tricky then :)
I've written an article which contains a proof of concept, support classes and a test class which demonstrates how Super Type Tokens can be retrieved by your classes at runtime. In a nutshell, it allows you to delegate to alternative implementations depending on actual generic parameters passed by the caller. Example:
TimeSeries<Double>
delegates to a private inner class which uses double[]
TimeSeries<OHLC>
delegates to a private inner class which uses ArrayList<OHLC>
See:
Thanks
Richard Gomes - Blog