Re: RFC - Parameter Objects

I've used the approach where every set of parameters has its own class.

use Attribute::Property;

{
    package Param::function;
    sub new : New;

    # XXX - Both need anchors?
    sub type  : Property { /Order|Return/ }
    sub month : Property { grep /$_[1]/, 1 .. 12 }
}
sub function { 
    my $self = shift;
    ...
}
[download]

After which you can do

my %params = (
    type  => qr/Order|Return/,
    month => sub { my $month = shift; return grep { /$month/ } (1 .. 1
+2) }
);
my $param = Param::function->new(\%params);

$param->type = 'Return';
$param->month = 3;

print $param->type;  # prints 'Return'
print $param->month; # prints 3

# the following two method calls will fail (croaking)
$param->type = 'Ovid';
$param->month = 13;
[download]

But I dislike param objects. The idea is great, but it's too much work in practice. Not because I created many classes, but because it's just too much work to create objects every time you want to pass parameters. I ended up using

my $param = @_ == 1 ? shift : Param::function->new({ @_ });
[download]

everywhere and not actually using the parameter classes.

Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

Comment on Re: RFC - Parameter Objects Select or Download Code

Replies are listed 'Best First'.

Re: Re: RFC - Parameter Objects
by Ovid (Cardinal) on May 15, 2003 at 15:35 UTC

Juerd wrote:

But I dislike param objects. The idea is great, but it's too much work in practice. Not because I created many classes, but because it's just too much work to create objects every time you want to pass parameters.

That just means I need to update the POD to make it more clear what these objects are for. Thanks!

Parameter objects aren't for every subroutine or method. Instead, imagine the following code:

sub foo {
    my ($quantity, $mangled, $item, $color, $puppies) = @_;
    ...
}

sub bar {
    my ($thing, $quantity, $color, $item) = @_;
    ...
}

sub baz {
    my ($quantity, $mushroom, $color, $item, $limit) = @_;
    ...
}

sub quux {
    my ($quantity, $color, $item, $kittens) = @_;
    ...
}
[download]

Now imagine that those are four subroutines out of about 30. If the identically named variables are truly identical, but we start to get large parameter lists (this is frequent when we're passing parameters through a chain of functions and wind up with tramp data) then we have a "data clump". This clump can be grouped in one parameter object with a standard set of validations applied. This reduces the number of arguments to the various subroutines and makes it less likely that we'll forget to validate the variables.

In the above example, we may simply have one parameter object encapsulating the quantity, color, and item. We won't have thirty parameter objects. These objects are merely a refactoring tool to lower the amount of code duplication (see Martin Fowler's book on refactoring for more information on parameter objects).

Another benefit of parameter objects is that it might make it clear that another class is required. In the above example, it might be the case that quantity, color and item can be grouped into a "Product" class or something similar. However, when these parameters are constantly separated, such redesign of code may not be apparent.

Cheers,
Ovid

New address of my CGI Course.
Silence is Evil (feel free to copy and distribute widely - note copyright text)

[reply]
[d/l]


Come for the quick hacks, stay for the epiphanies.
	PerlMonks