Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > How to implement Factory Pattern in Java

Reply
Thread Tools

How to implement Factory Pattern in Java

 
 
Edward A Thompson
Guest
Posts: n/a
 
      01-19-2004
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?
 
Reply With Quote
 
 
 
 
Oscar Kind
Guest
Posts: n/a
 
      01-19-2004
Edward A Thompson <(E-Mail Removed)> 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.
 
Reply With Quote
 
 
 
 
Andrew Hobbs
Guest
Posts: n/a
 
      01-20-2004

"Edward A Thompson" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) 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




 
Reply With Quote
 
Ed Thompson
Guest
Posts: n/a
 
      01-20-2004

> 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?


 
Reply With Quote
 
Thomas Weidenfeller
Guest
Posts: n/a
 
      01-20-2004
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

 
Reply With Quote
 
iksrazal
Guest
Posts: n/a
 
      01-20-2004
Ed Thompson <(E-Mail Removed)> wrote in message news:<zb%Ob.245605$(E-Mail Removed). 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Abstract factory and Factory pattern C# ASP .Net 4 07-31-2008 03:22 PM
A sample program to implement a factory design pattern sunny C++ 7 12-07-2006 04:56 PM
A sample program to implement a factory design pattern sunny C++ 0 12-06-2006 02:28 PM
A sample program to implement a factory design pattern sunny C++ 0 12-06-2006 02:28 PM
Abstract Factory or Factory Method pattern question.... Medi Montaseri C++ 17 09-03-2003 06:50 AM



Advertisments