Re: Polymorphism in Java SE?
Stefan Ram <ram@zedat.fu-berlin.de> wrote:
For teaching purposes, I'd like to know a Java-SE method
that returns an object whose class is only known at runtime
and can be shown to have at least two possibly values by
running a small program.
Doesn't this describe just about any factory method? This seems to be pretty
fundamental to the point of interfaces, and you should be able to find or
create dozens of examples.
It would be best if this would be a static method that can
be called without any preparation.
Calendar.getInstance returns a Calendar object that's actually a subclass, for
instance. Swing's UIManager.getLookAndFeel() will return a different
LookAndFeel subclass depending on platform and settings.
In both cases (and most useful cases of this), there's a common parent type
that all returned types will extend or implement, so the caller doesn't
actually have to do instanceof - just use the methods on the parent type.
That's what polymorphism is intended for. If you're calling instanceof,
you're likely doing something a bit odd.
For example, it would be great, if Java SE had an ?input? method,
which returned ?java.lang.Integer? or ?java.lang.String?
depending on the text typed in the console.
1) If you think this would be great, write one. It's probably not more than a
dozen lines of code.
2) I think this would be less great than you think. It's rare that you want
to have random objects without a useful parent class/interface by which you
handle them all.
public class Main
{
public static void main
( final java.lang.String[] args )
{
java.lang.System.out.println
( java.lang.System.in.input().getClass() ); }}
Which would print ?java.lang.Integer? (when one
enters ?123?) or ?java.lang.String? (when one enters ?abc?).
In practice, you ALWAYS want the String, then parse it to a more specific
type, with error handling and fallback in a type-safe way.
The usual approach is to put objects of different classes
into a heterogeneous container, then reading them in again,
and - surprise! - get objects of different classes.
Huh? You still only get out what you put in. And you don't need a container,
just use a variable. "Object o" can be any reference type.
Possibly, somewhere in the huge Java-SE API there is a little
known field or method I could use.
For teaching purposes, why not write (or have students write) it? Something
like:
/*
* parse a String, returning a String, Boolean, or Integer, depending on
* the contents of the string. Returns null for null input.
*/
public static Object parseString(String input) {
if (input == null)
return null;
try {
// attempt to parse as int. if success, return it.
return new Integer(Integer.parseInt(input));
} catch (NumberFormatException nfe) { }
if ("true".equals(input))
return Boolean.TRUE;
else if ("false".equals(input))
return Boolean.FALSE;
else
return input;
}
Keep in mind that this is a crappy thing to do most of the time. You're going
to force users of this method to basically have the same if/else if/else logic
you have here, except with instanceof instead of testing directly.
--
Mark Rafn dagon@dagon.net <http://www.dagon.net/>