Is a static method sufficient to call it factory?
 

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

Re: Is a static method sufficient to call it factory?
 

f.vivoli@gmail.com 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.

Re: Is a static method sufficient to call it factory?
 

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.

Re: Is a static method sufficient to call it factory?
 

f.vivoli@gmail.com 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.

Re: Is a static method sufficient to call it factory?
 

<f.vivoli@gmail.com> 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

Re: Is a static method sufficient to call it factory?
 

f.vivoli@gmail.com 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/...g/java/gui/faq
http://www.uni-giessen.de/faq/archiv....java.gui.faq/

Re: Is a static method sufficient to call it factory?
 

f.vivoli@gmail.com 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/

Re: Is a static method sufficient to call it factory?
 

f.vivoli@gmail.com 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.

Re: Is a static method sufficient to call it factory?
 

f.vivoli@gmail.com 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

Re: Is a static method sufficient to call it factory?
 

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