How to implement Factory Pattern in Java

Discussion in 'Java' started by Edward A Thompson, Jan 19, 2004.

  1. 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, Jan 19, 2004
    #1
    1. Advertising

  2. Edward A Thompson

    Oscar Kind Guest

    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.
    Oscar Kind, Jan 19, 2004
    #2
    1. Advertising

  3. Edward A Thompson

    Andrew Hobbs Guest

    "Edward A Thompson" <> wrote in message
    news:...
    > 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
    Andrew Hobbs, Jan 20, 2004
    #3
  4. Edward A Thompson

    Ed Thompson Guest


    > 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, Jan 20, 2004
    #4
  5. 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
    Thomas Weidenfeller, Jan 20, 2004
    #5
  6. Edward A Thompson

    iksrazal Guest

    Ed Thompson <> wrote in message news:<zb%Ob.245605$>...
    > > 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
    iksrazal, Jan 20, 2004
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Medi Montaseri
    Replies:
    17
    Views:
    834
    Medi Montaseri
    Sep 3, 2003
  2. sunny
    Replies:
    7
    Views:
    312
  3. sunny
    Replies:
    0
    Views:
    279
    sunny
    Dec 6, 2006
  4. sunny
    Replies:
    0
    Views:
    318
    sunny
    Dec 6, 2006
  5. C#
    Replies:
    4
    Views:
    386
Loading...

Share This Page