Re: Factory design pattern question
Mark Rafn wrote:
Your factory can test the system property java.class.version - if it's 49 or
higher, then JDK1.5 classes can be loaded using Class.forName(). If it's 48
or less, then only JDK1.4 classes are avaialable, and you can use your
version.
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).