«

Is there any reason that the Factory Pattern cannot be implmented with
a static getClass method in the base class?

Rather than instantiate a factory, then call its getClass method (2
steps):

CalculatorFactory f = new CalculatorFactory ();
Calculator c = f.getClass(someIndentifyingString);

I was thinking of instantiating the final class I want by calling a
static method in the base class:

Calculator c = Calculator.getClass(someIndentifyingString);

Is there a flaw in this strategy? What am I missing?

Edward A Thompson <> wrote:
> Is there any reason that the Factory Pattern cannot be implmented with
> a static getClass method in the base class?
>
> Rather than instantiate a factory, then call its getClass method (2
> steps):
>
> CalculatorFactory f = new CalculatorFactory ();
> Calculator c = f.getClass(someIndentifyingString);
>
> I was thinking of instantiating the final class I want by calling a
> static method in the base class:
>
> Calculator c = Calculator.getClass(someIndentifyingString);
>
> Is there a flaw in this strategy? What am I missing?

Both options (i.e. a static and a non-static factory) are valid, but what
you want depends on how you use it. Personally, I've never encountered a
situation where I had to have a factory object. So for me, a factory class
with only static methods was sufficient.

Also, the first factory class I found in the Java 1.4.2 API also only
contains static methods. See javax.swing.plaf.basic.BasicIconFactory


Oscar

--
No trees were harmed in creating this message.
However, a large number of electrons were terribly inconvenienced.

"Edward A Thompson" <> wrote in message
news: m...
> Is there any reason that the Factory Pattern cannot be implmented with
> a static getClass method in the base class?
>
> Rather than instantiate a factory, then call its getClass method (2
> steps):
>
> CalculatorFactory f = new CalculatorFactory ();
> Calculator c = f.getClass(someIndentifyingString);
>
> I was thinking of instantiating the final class I want by calling a
> static method in the base class:
>
> Calculator c = Calculator.getClass(someIndentifyingString);
>
> Is there a flaw in this strategy? What am I missing?

Your suggestion is hardly a factory method. Not that it won't work, but you
are starting to mix code for how to make calculators with their functional
code. Plus it means the base class has to have code relating to its derived
classes. None of this is a good idea.

However you can still have a single call to a static method such as

Calculator c = CalculatorFactory.getClass(someIndentifyingString) ;

This doesn't mean you can't have the advantages of an instantiated object.
Just make the Factory class hold a singleton of itself and make the static
method call on that singleton.

Andrew

> Your suggestion is hardly a factory method.
I was suggesting it was an implmentation of the factory pattern, not a
factory method per se.

> you are starting to mix code for how to make calculators with their functional
> code.

True, but I believe I found a precedent in the java.util.Calendar class,
whose getInstance() method seems to be doing something similiar. Is
this different?

> Plus it means the base class has to have code relating to its derived
> classes.

True. Feedback on why this is bad?

Ed Thompson wrote:
> True, but I believe I found a precedent in the java.util.Calendar class,
> whose getInstance() method seems to be doing something similiar. Is
> this different?

I didn't check this specific method, but as a general rule: The Calender
class is a very bad example. It has a horrible design, and should only
serve as an example of how not to do things.

Sun has a tendency to have these static getDefault/getInstance etc.
methods in a number of their APIs in order to hide a particular
implementation. It is convenient, but not a very clean design.

>> Plus it means the base class has to have code relating to its derived
>> classes.
>
>
> True. Feedback on why this is bad?

Changes you do in the derived class can have an unexpected impact on the
superclass. Which is not what you want.

Changing the derived class might require to adapt the superclass, which
is also not what you want.

/Thomas

Ed Thompson <> wrote in message news:<zb%Ob.245605$. rr.com>...
> > Your suggestion is hardly a factory method.
> I was suggesting it was an implmentation of the factory pattern, not a
> factory method per se.
>

There really are two types of factory patterns per se GOF - factory
method and abstract factory.

As I understand it, you use 'factory method' when the invoker of the
factory knows which class he wants. There is one common abstract class
for all classes requested (the return value of getClass(String
identifier) ) . The implementation can get done with static ints, or
sometimes pass the name of the class to be used via
classForName.newInstance() .

Abstract factory differs in that the getClass() method returns a
factory itself - hence the name abstract factory. Here, typically the
factory decides which factory to return. Or alternatively, there is a
getFactoryType1() and getFactoryType2() methods.

> > you are starting to mix code for how to make calculators with their functional
> > code.
>
> True, but I believe I found a precedent in the java.util.Calendar class,
> whose getInstance() method seems to be doing something similiar. Is
> this different?
>
> > Plus it means the base class has to have code relating to its derived
> > classes.
>
> True. Feedback on why this is bad?

Tight coupling. One of the ideas of patterns is to encapsulate change.
Changing one part and affecting the other part should be avoided.

Also, getInstance() virtually always means a Singleton - another
pattern altogether. Singletons are a generator of a single class,
typically with expensive network parameters that are always the same
and you want only one way to do it, versus factories which can return
several different classes of an abstract type.

Hope that helps,
iksrazal