Re: a question about factory method
On 12/18/2014 1:43 PM, John wrote:
Eric,
Your reply goes off the topic. I didn't mean digging deep into Calendar thing. Since you mentioned it, I use it as an example to ask.
I meant to ask How to use factory method to return different objects(which belong to the same parent class). A couple of repliers, including you, mentioned that as one of several advantages of using factory versus using a public constructor.
Sorry for misunderstanding the thrust of your question.
As to *how* a factory method might choose which of several classes
to return, you already illustrated one way (paraphrased):
public static Calendar getInstance(Date aDate, int choice) {
if (choice == 1) {
... //return a GregorianCalendar object
} else if (choice == 2) {
... //return a MayanCalendar object
} else if (choice == 3) {
... //return a JulianCalendar object
} else {
return null;
}
}
To me, this doesn't seem a huge advantage: The caller who writes
`getInstance(date, 2)' could just as easily write `new MayanCalendar()'
with about the same effect. So let's think of another possibility
(again, this is largely made-up): The switch from the Julian to the
Gregorian calendar happened at different times in different parts of
the world, so the particular kind of Calendar to use is a function
of both the Date and the Locale. We might write something like:
public static Calendar getInstance(Date date, Locale locale) {
Date cutover = ...; // locale's Gregorian adoption date
if (date.compareTo(cutover) < 0) {
return new JulianCalendar(date);
} else {
return new GregorianCalendar(date);
}
}
The caller needn't worry about determining `cutover' (it's probably not
a one-liner!), he just gets the "right kind" of Calendar for the Date
in question at the specified Locale.
Approaches like this, though, require the factory method to have an
enumeration of all the possibilities, built right into the Java source.
Another possibility is often used in "provider" or "plugin" styles: The
factory method consults an environment variable or a configuration file
or a database or some such, and gets the name of a suitable class -- as
a String. Then it can use Class.forName() to load the named class, and
can create an instance by invoking the class' constructor reflectively.
This style requires more effort to set up, but is much more flexible: To
introduce a new class you needn't change a single line of the factory
method or its caller; you write your new class, put it in a .jar (most
likely), and change the environment variable or config file. This is
(more or less) how Swing loads pluggable look-and-feel implementations,
and similar approaches are used for things like externally-supplied
cryptographic suites.
--
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM