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)