water has asked for the wisdom of the Perl Monks concerning the following question:

In the chatterbox today, I asked for help about a "factory" class.

"Factory" in quotes, as the chatterbox denizens quickly set me straight and let me know I didn't have the concept of a factory object right. Thanks all for your help.

I'm still curious about the idea, and wanted to ask the OO design gurus here in SOPW.

Here's my problem/idea:

I was seeking an object that would construct itself as the right type, depending on constructor parameters.

A factory class produces widget objects; it doesn't become a widget. In contrast, I was thinking about something like a seed: a seed doesn't produce plants, it turns itself into a plant.

Here's some pseudo-code: 


# untested code
#
# factory approach
my $factory = AnimalFoodFactory->new; 
my $food_object = 
AnimalFoodFactory->prepare_correct_chow(
    animal=> 'lion');
# now ref $food_object eq 'LionFood'

# "seed" (?) approach
my $food_object = AnimalFoodPreparer->new(animal=> 'lion');
# now ref $food_object eq 'LionFood'

[download]
My question: does this approach (a constructor that returns something of the right type depending on its parameters) have a name?

And does the approach make sense, or is Bad Practice?

Curious --

water

Replies are listed 'Best First'.
Re: OO: Factory vs. "Seed" (?) pattern
by dragonchild (Archbishop) on May 14, 2005 at 03:38 UTC
    Let's turn this on its head. Basically, you're saying
    • I have a class and a method of that class. Let's call them Foo and bar().
    • I have a set of parameters. Let's call them @params.
    • I want to get back an object (called $obj) blessed into class Foo::Child.

    In other words, you have 

    my $obj = Foo->bar( @params );
isa_ok( $obj, 'Foo::Child' );

    [download]
    A factory does not need to be an object, regardless of whatever anyone told you. A factory can be a class. You have a factory pattern and it makes perfect sense. I have a very similar setup in Excel::Template with Excel::Template::Factory. I pass it a nodename and it gives me back an object that represents the node. That is the definition of a factory. Whether it's a class method or an object method is a function of whether or not you need more than one factory running at the same time.
    • In general, if you think something isn't in Perl, try it out, because it usually is. :-)
    • "What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against?"
[reply]
[d/l]
Re: OO: Factory vs. "Seed" (?) pattern
by lachoy (Parson) on May 14, 2005 at 09:54 UTC

    I think it makes sense because that's exactly what Class::Factory does. I don't think it has a name because some other OO languages don't allow you to do this -- if you say 'new Foo()' then you're getting back an object of class 'Foo', not just something that implements 'Foo'. That's why those other languages often use class (or static) methods to implement a factory, like 'Foo.create( ... )'

    Chris
    M-x auto-bs-mode

[reply]
Re: OO: Factory vs. "Seed" (?) pattern
by gaal (Parson) on May 14, 2005 at 09:57 UTC
    What does this line do?

    my $factory = AnimalFoodFactory->new;

    You don't seem to be using $factory afterwards.

[reply]
[d/l]
[select]
      Good catch. I meant this 
      # UNTESTED
# factory approach
my $factory = AnimalFoodFactory->new; 
my $food_object = $factory->prepare_correct_chow(animal=> 'lion');
# now ref $food_object eq 'LionFood'

      [download]
[reply]
[d/l]
        A factory is normally implemented as a class method ("static method" in Java parlance). You can do this then, as dragonchild pointed to above.

        my $food_object = AnimalFoodFactory->prepare_correct_chow(animal => 'lion');

        Incidentally, there's a technique for cheap aliasing of long package names that can in a pinch do some of the work of factories. Take a look at my home node.

[reply]
[d/l]

Back to Seekers of Perl Wisdom