Re: Factory design pattern question

Mark Rafn wrote:


Reflection ... ugh. And is it even necessary? What if you have

public abstract class A {
    // Compiled with 1.4
    public abstract void foo ();
}

public class B extends A {
    // Compiled with 1.4
    public void foo () {
        // Do stuff without using 1.5-only library classes
    }
}

public class C extends A {
    // Compiled with 1.5
    public void foo () {
        // Do stuff using 1.5-only library classes
    }
}

public class AFactory {
    public static A getA () {
        if (jre is 1.5) return new C();
        return new B();
    }
}

public class Main {
    public static void main (String[] args) {
        A myA = AFactory.getA();
        myA.foo();
    }
}

Assume the test in getA works perfectly. In a 1.4 JRE, getA returns a B
and C's never constructed or even invoked somehow statically, so class C
never even gets loaded. The classloader certainly doesn't try to load
the 1.5-specific dependencies C's foo method references (then fail, then
complain). It probably doesn't even see the C.class file's contents at
all (and maybe complain about something 1.5-specific in that).

In a 1.5 JRE, getA returns a C, so the classloader loads C.class in
getA. C.class may (but probably doesn't) cause problems if a 1.4 VM
loads it, but a 1.5 VM loads it. Calling C's constructor may invoke
1.5-specific library code, but the 1.5 library is present. Calling foo
from main definitely calls 1.5 library code, but again the 1.5 library
is present for the classloader to find.

Unless there's something subtle I'm missing here, there's no apparent
need for reflectively loading classes (such as C) explicitly here (in
getA or elsewhere).