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

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

Relevant Pages

  • Re: Evolution is not random?
    ... Below is the definition that best meets my "intent". ... "intent" than the third or later definitions of a guiding agent. ... "optimize" is used in the pattern sense and not design sense right? ... pattern, not something that is different from "pattern". ...
    (talk.origins)
  • Re: Eleven questions Pitman refuses to answer. was Non-beneficial
    ... necessity of deliberate design behind most of the key differences. ... deliberate design without the need for common descent. ... The problem with that is that any pattern at all, or no pattern at all, ... If on the other hand we allow that anything can actually be rules, out, we can certainly rule out the idea that only design could result in a nested hierarchy, right? ...
    (talk.origins)
  • Re: Eleven questions Pitman refuses to answer. was Non-beneficial
    ... I've already discussed your ideas on the nested pattern with you ... to have the one that mimics exactly what we would see from common descent. ... But in fact you couldn't falsify design that way either. ... > combined with mindless natural selection can produce the vast variety ...
    (talk.origins)
  • Re: Pitmans Miller Time
    ... this evidence could equally be explained by common ... design and common descent. ... The real absence in the pattern is more than ... You have presented no metric of "level of functional complexity". ...
    (talk.origins)
  • Re: If SETI researchers were to take Noctilucas advise, they would pack up and go home
    ... For a pattern to count as a specification, ... recognized from our background knowledge of number theory---prime ... First because ID theory doesn't yield an inference of Intelligent ... Design all that easily contrary to the straw man erected by atheists ...
    (talk.origins)