This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
The references are in Effective Java™ by Joshua Bloch. Unfortunately I can't find my copy because all our furniture is in the wrong place while we have builders in, so I can't give you the page number..
List<T> The "T" is a formal type parameter..
List<String> The "String" is an actual type parameter.
Joined: Jun 23, 2011
Thanks both. I've been trying to use these to accomplish some form of 'covariant return' typing, with little success.
I have written an abstract class, called 'Field' , defined as:-
public abstract class Field
abstract double getValue();
public class Real extends Field
public double getValue()
Now for another class, 'Complex', that also extends field, then it's implementation of 'getValue()', I want
to have a different return type for, other than 'double' (either 'void' or an error type). How could this be acheived?
So maybe the class would look like:-
public class Complex extends Field
public void getValue()
Usually (based on my 30 seconds of googling) the "covariant" return type is supposed to be related in some way to the base return type, and usually it's supposed to be a subclass of the base return type.
That doesn't seem to be the case in your example, although since you haven't voted for an actual type to represent a Complex object it's hard to tell.
Joined: Oct 13, 2005
Yes, a covariant return type (available since Java5) is a subclass of the superclass' method's return type. That has to do with overriding and polymorphism, not with the <T> notation at all.