Is a static method sufficient to call it factory?

Discussion in 'Java' started by f.vivoli@gmail.com, Jul 28, 2005.

  1. Guest

    Hi everyone,

    I've just a doubt...

    Talking about factories why someone propose the way

    Factory.getInstance().createClass(aType);

    instead of simply

    Factory.createClass(aType);

    That is,
    why the singleton?

    In the end, is a class with a static method eligible to be an use of a
    factory method pattern? It doesn't resemble the structure of the GOF
    pattern, since it doesn't use subclassing...

    Suppose that what createClass() method does is to instantiate a
    concrete class
    based on the parameter.


    cheers,
    Francesco
    , Jul 28, 2005
    #1
    1. Advertising

  2. wrote:
    > Hi everyone,
    >
    > I've just a doubt...
    >
    > Talking about factories why someone propose the way
    >
    > Factory.getInstance().createClass(aType);
    >
    > instead of simply
    >
    > Factory.createClass(aType);
    >
    > That is,
    > why the singleton?
    >
    > In the end, is a class with a static method eligible to be an use of a
    > factory method pattern? It doesn't resemble the structure of the GOF
    > pattern, since it doesn't use subclassing...


    Actually, one of the reasons to use a singleton is that the getInstance
    method can return a subclass. So some subclassing is really used, which
    makes it more similar to a factory method.
    Looks a bit strange implementation, though. The singleton should always
    return the same instance, whereas the factory patterns are made to work
    with more subclasses.
    Andrea Desole, Jul 28, 2005
    #2
    1. Advertising

  3. Guest

    Well, actually the getInstance returns always the same instance of the
    Factory class...
    For subclassing I was meaning that the allocated objects do not
    necessarily belong to the same class hierarchy of the factory.
    , Jul 28, 2005
    #3
  4. wrote:
    > Well, actually the getInstance returns always the same instance of the
    > Factory class...


    usually yes, but it doesn't have to. It can also return a subclass of
    Factory. If I understand correctly what you say


    > For subclassing I was meaning that the allocated objects do not
    > necessarily belong to the same class hierarchy of the factory.
    >


    It depends on what you mean by "allocated object". If you mean the
    result of createClass then no, it doesn't have to be a factory subclass.
    It shouldn't be. But you didn't give any information about the return
    type of getInstance (I assume it's Factory) and createClass.
    So, supposing that getInstance returns a Factory, then createClass is
    your factory method. Now getInstance can return a subclass of Factory,
    and that subclass can implement its own crateClass method. This is the
    idea of the factory method.
    Andrea Desole, Jul 28, 2005
    #4
  5. Chris Smith Guest

    <> wrote:
    > Talking about factories why someone propose the way
    >
    > Factory.getInstance().createClass(aType);
    >
    > instead of simply
    >
    > Factory.createClass(aType);


    [...]

    > In the end, is a class with a static method eligible to be an use of a
    > factory method pattern? It doesn't resemble the structure of the GOF
    > pattern, since it doesn't use subclassing...


    I think you're getting caught up in terminology here. Does it really
    matter if the code fits under the umbrella name that the GoF book gives
    to its pattern. Read design pattern books to broaden your repertoire of
    design approaches, but attachment to names and classification is not the
    point here.

    Both of the approaches above can have advantages. The static factory
    method is certainly easier; no argument there. For that reason, it's
    probably best to use it when it meets your needs, unless you're
    designing a potentially published API that might need additional
    flexibility in the future. If you're writing published APIs, then some
    degree of long-term planning is called for here, and you'll want to
    think this through a bit more.

    The advantage of the getInstance() approach arises when you're a bit
    less coupled to the resulting code. It allows you to encapsulate the
    entire interface to some external module within a single object, which
    can then return the objects your code (or client) needs. At a minimum,
    that ensures that you only have to look up the provider once, if you use
    some sort of provider interface registration via properties files in
    resources, etc. It also allows the service provider to maintain state
    about the application's usage of it, and other things along those lines.

    --
    www.designacourse.com
    The Easiest Way To Train Anyone... Anywhere.

    Chris Smith - Lead Software Developer/Technical Trainer
    MindIQ Corporation
    Chris Smith, Jul 28, 2005
    #5
  6. wrote:
    > Talking about factories why someone propose the way
    >
    > Factory.getInstance().createClass(aType);
    >
    > instead of simply
    >
    > Factory.createClass(aType);
    >
    > That is,
    > why the singleton?


    Without knowing the inner details of the involved methods it is
    difficult to say, but very often a singleton is just used to hide a
    static method or a global variable, so the code looks more
    object-oriented. It is maybe the most common abuse of the singleton
    design pattern.

    Should this be the case then I would suggest to drop the singleton. Why
    do you want to fool yourself with a singleton, if you don't need any of
    its features?

    > In the end, is a class with a static method eligible to be an use of a
    > factory method pattern? It doesn't resemble the structure of the GOF
    > pattern, since it doesn't use subclassing...


    Do you want to write more code just to follow a book, or do you want to
    have simpler (so less error prone) code? If a GoF pattern doesn't fit,
    it doesn't fit, so why spend extra effort to make it fit?

    /Thomas
    --
    The comp.lang.java.gui FAQ:
    ftp://ftp.cs.uu.nl/pub/NEWS.ANSWERS/computer-lang/java/gui/faq
    http://www.uni-giessen.de/faq/archiv/computer-lang.java.gui.faq/
    Thomas Weidenfeller, Jul 28, 2005
    #6
  7. wrote:
    >
    > Talking about factories why someone propose the way
    >
    > Factory.getInstance().createClass(aType);
    >
    > instead of simply
    >
    > Factory.createClass(aType);


    Why not define createClass as

    public static AProduct createClass(AType aType) {
    return getInstance().createClass0(aType);
    }

    Tom Hawtin
    --
    Unemployed English Java programmer
    http://jroller.com/page/tackline/
    Thomas Hawtin, Jul 28, 2005
    #7
  8. wrote:
    > Hi everyone,
    >
    > I've just a doubt...
    >
    > Talking about factories why someone propose the way
    >
    > Factory.getInstance().createClass(aType);
    >
    > instead of simply
    >
    > Factory.createClass(aType);
    >
    > That is,
    > why the singleton?
    >
    > In the end, is a class with a static method eligible to be an use of a
    > factory method pattern? It doesn't resemble the structure of the GOF
    > pattern, since it doesn't use subclassing...
    >
    > Suppose that what createClass() method does is to instantiate a
    > concrete class
    > based on the parameter.
    >
    >
    > cheers,
    > Francesco
    >


    You don't need an Abstract Factory to use a Singleton Pattern to get
    access to it, but the reason for doing so in the GoF Abstract Factory
    pattern, is so that we can *change* the factory that is actually
    returned and so we can call the createClass() method on any kind of factory.

    For example, there could be some setup code that your app runs at
    startup, that decides which Concrete Factory to initialise the Abstract
    Factory with. Then the rest of the code base simply uses the
    AbstractFactory as you have seen, none the wiser that someone made a
    decision as to what the real concrete factory should be.
    Andrew McDonagh, Jul 28, 2005
    #8
  9. Harald Guest

    writes:
    > Talking about factories why someone propose the way
    >
    > Factory.getInstance().createClass(aType);
    >
    > instead of simply
    >
    > Factory.createClass(aType);
    >
    > That is,
    > why the singleton?
    >
    > In the end, is a class with a static method eligible to be an use of a
    > factory method pattern? It doesn't resemble the structure of the GOF
    > pattern, since it doesn't use subclassing...


    The difference is that your Factory may be the implementation of some
    interface. In addition, you may want to hand the Factory object to
    some other class that wants to use it. In both cases you need an
    instance, even if it is always the same one.

    Having said that, I realise that I would probably not call a static
    method that happens to return an object --- even freshly created --- a
    factory.-)

    Harald.

    --
    ---------------------+---------------------------------------------
    Harald Kirsch (@home)|
    Java Text Crunching: http://www.ebi.ac.uk/Rebholz-srv/whatizit/software
    Harald, Jul 28, 2005
    #9
  10. Guest

    Chris Smith wrote:

    > I think you're getting caught up in terminology here. Does it really
    > matter if the code fits under the umbrella name that the GoF book gives
    > to its pattern.


    not at all. Simply it was a matter of curiosity...

    > The advantage of the getInstance() approach arises when you're a bit
    > less coupled to the resulting code. It allows you to encapsulate the
    > entire interface to some external module within a single object, which
    > can then return the objects your code (or client) needs. At a minimum,
    > that ensures that you only have to look up the provider once, if you use
    > some sort of provider interface registration via properties files in
    > resources, etc. It also allows the service provider to maintain state
    > about the application's usage of it, and other things along those lines.



    Ok this was the use I was thinking of. But the reason I posted was that
    some days ago I encountered a class like this:


    public class AFactory{

    private static Factory instance

    private AFactory(){}

    public static AFactory getInstance(){
    if(instance==null)
    instance=new AFactory();
    return instance;
    }

    public AClass createClass(String type){
    if(type.equals("type1"))
    return new AConcreteClass1();
    else
    return new AConcreteClass2();
    }

    }


    AFAIK there is no use of a singleton like this...
    So I was thinking that if the problem is to instantiate a concrete
    class
    within a hierarchy based upon some switch (ie, no resource lookup is
    needed or the like) a factory simply reduces to a static method, that
    is what I have been using until now.


    >
    > --
    > www.designacourse.com
    > The Easiest Way To Train Anyone... Anywhere.
    >
    > Chris Smith - Lead Software Developer/Technical Trainer
    > MindIQ Corporation
    , Jul 29, 2005
    #10
  11. Guest

    Harald wrote:

    > The difference is that your Factory may be the implementation of some
    > interface. In addition, you may want to hand the Factory object to
    > some other class that wants to use it. In both cases you need an
    > instance, even if it is always the same one.
    >


    ok this was the case I was thinking of. But still if the factory
    instance that is returned simply has a method createClass(), which is
    the difference of making this createClass static?

    I admit to feel weak on the difference between calling an instance
    method on a static object and calling a static method, but it sounds to
    me that it is not really a big one.
    Am I wrong?


    > Having said that, I realise that I would probably not call a static
    > method that happens to return an object --- even freshly created --- a
    > factory.-)
    >


    Ok, this is what I was asking for;)

    Thanks,
    Francesco

    > Harald.
    >
    > --
    > ---------------------+---------------------------------------------
    > Harald Kirsch (@home)|
    > Java Text Crunching: http://www.ebi.ac.uk/Rebholz-srv/whatizit/software
    , Jul 29, 2005
    #11
  12. HK Guest

    wrote:
    > Harald wrote:
    >
    > > The difference is that your Factory may be the implementation of some
    > > interface. In addition, you may want to hand the Factory object to
    > > some other class that wants to use it. In both cases you need an
    > > instance, even if it is always the same one.
    > >

    >
    > ok this was the case I was thinking of. But still if the factory
    > instance that is returned simply has a method createClass(), which is
    > the difference of making this createClass static?


    If the createClass() is static in the Factory class,
    there is no point of passing an instance around,
    because the instance does not contain the method.
    In particular you could not do things like:

    Factory myFac = new Factory();
    myFac.createClass();

    Consequently you could not pass myFac to some
    method which requires a parameter that is only
    some interface implemented by my Factory.

    Harald.
    HK, Jul 29, 2005
    #12
    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. ali
    Replies:
    0
    Views:
    4,421
  2. Matthias Kaeppler
    Replies:
    22
    Views:
    927
    Thomas G. Marshall
    May 24, 2005
  3. Medi Montaseri
    Replies:
    17
    Views:
    837
    Medi Montaseri
    Sep 3, 2003
  4. William Payne

    Sufficient error checking of strtol()?

    William Payne, Feb 2, 2004, in forum: C Programming
    Replies:
    5
    Views:
    1,238
    AJ Mohan Rao
    Feb 3, 2004
  5. C#
    Replies:
    4
    Views:
    389
Loading...

Share This Page