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]

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.