Re: Method parameters validation and inheritance

I would probably try to structure my code so as to avoid the use of $self->SUPER::whatever(). Then I wouldn't need to have a separate method (that subclasses override) to store the spec for Params::Validate.

You can still pull the spec out of the method itself using lexicals and closures.

{
    my $spec_sub = sub {
        { path => 0 }
    };

    sub open_for_reading {
        validate( @_, $spec_sub->() );
    }
}
[download]

(Note that this is a variation on a suggestion from the Params::Validate author, autarch, from Re: Params::Validate - a powerful tool for robust subroutine design. I use a sub instead of a flat out lexical because of the case where you have a default set to an anonymous reference (e.g., "{}"). In that case, you'll get the same reference every time the method is called—not a new empty one as you might expect. Using an anonymous sub and calling that means you get a fresh new data structure every time.)

Back to the design problem...

If you have a bunch of stuff in open_for_reading, decompose it into private methods that the main open_for_reading then calls. The overridden open_for_reading in the child class can then call the same methods (or some subset of them). They enforce their own parameters, and callers will have to abide by them but won't have to have their own copy of them.

Since we're not talking about real code here, I'm necessarily doing a lot of handwaving. Please let me know if I'm not getting my point across.

As for part two of your question, I'd probably do this:

sub method {
    my $self = shift;

    $self->method_init;
    $self->_method;
    $self->method_cleanup;
}
[download]

If you don't like the "_method" naming, you might pick another suffix ("_exec", maybe). I'd prefer a standard set of suffixes over a standard set of prefixes.

Another approach would be to make that group of methods into an object. It can do its initialization during construction, cleanup in DESTROY, and the method itself can keep its name. Then you subclass it and override that one method. I don't think that's always a good idea, but it definitely takes the clutter off somewhere else, and that's often a good thing.

Comment on Re: Method parameters validation and inheritance Select or Download Code