If a collection of parameterizations that would have been passed as coderefs into a constructor deserve "a life of their own", then the override method makes more sense. You create a named class that contains the code to create this newly-abled object.

So, some objects have instance-specific behavior, while other objects share behavior.

For an interesting way to eliminate the distinction, see the Self language, or look at Perl workalikes like Class::Prototyped.

I like using the template method for factory operations (i.e., bless a new object that is not necessiarily part of the class you are doing this from). This allows you to avoid hard-coding the class you bless into. Example (admittedly arbitrary):

package Foo;
sub FACTORY_CLASS () { 'Bar' }

sub make_new_bar 
{
    my $self = shift;
    my @params = @_;
    bless \@params, $self->FACTORY_CLASS();
}
[download]

This allows a subclass to easily change the class of the object without having the override the entire factory method, which could be quite complex and would lead to a lot of code duplication.

It's important that FACTORY_CLASS is called in $obj->method() form, and not plain method() form. Otherwise, subclasses won't be able to override it, which is the whole point.

Nothing stopping you from doing that:

my $sub = sub {
 . . . 
};
my $obj1 = Foo->new( $sub );
my $obj2 = Foo->new( $sub );
[download]

----
I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer

: () { :|:& };:

Note: All code is untested, unless otherwise stated

I meant two different modules that want to use the same sub ref.