my personal definition: 

factory method:
  method, that creates a object, 
  because new(...) is not sufficient
  in that case

imho there's too much babbling about design patterns und too
little pragmatism. who cares if it's pattern #1 or pattern #2.

it's more a matter of good taste as a matter of applying rules.

especially in java I have seen ridiculous numbers of classes doing 
trivial stuff using factories, abstract classes, interfaces, proxies,
adapters, delegates and the like. it's often considered by so called
architects to be good software if it uses several design pattern 
no matter what for...


> --- Ursprgliche Nachricht ---
> Von: "Sam Kong" <sam.s.kong / gmail.com>
> An: ruby-talk / ruby-lang.org (ruby-talk ML)
> Betreff: Re: Is this a kind of design patterns?
> Datum: Thu, 23 Mar 2006 01:53:51 +0900
> 
> 
> Wilson Bilkovich wrote:
> > That's the "Factory Method" pattern.  It's handy when you want
> > SomeClass.new to return an instance of SomeOtherClass, or just when
> > you want things to be easier to read.
> >
> > One of my favorite examples (I think this is a Martin Fowler trick) is:
> > some_date = december(10,2006)
> 
> At first I thought so.
> But the definition of "Factory Method Pattern" bothered me.
> The definition of "Factory Method Pattern" is:
> 
> "Define an interface for creating an object, but let subclasses decide
> which class to instantiate. Factory Method lets a class defer
> instantiation to subclasses. "
> 
> However, in my Color example, there's no subclassing involved.
> So the class itself is a factory as well as the product that the
> factory makes.
> Do you think that we can still call it "Factory Method Pattern"?
> 
> Sam
> 
>