Is a static method sufficient to call it factory?

F

f.vivoli

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
 
A

Andrea Desole

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.
 
F

f.vivoli

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.
 
A

Andrea Desole

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.
 
C

Chris Smith

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
 
T

Thomas Weidenfeller

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
 
T

Thomas Hawtin

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
 
A

Andrew McDonagh

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.
 
H

Harald

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.
 
F

f.vivoli

Chris said:
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.
 
F

f.vivoli

Harald said:
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
 
H

HK

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.
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,901
Latest member
Noble71S45

Latest Threads

Top