The problem sounds more like a functional programming one (where you focus on evaluating "expression")than OOP one. I don't think inheritance (though it might not what you really meant) it's necessarily good for customization and even less for flexibility. It leads to too tight a coupling.

OOP is a good way to deal with design time customization. At runtime, or so you could think, it's another story. Think about a calculator. It evaluates arbitrary expression at runtime. It all depends on how you model the problem and/or your spec.

As to how one might conceptualize overriding a sub, I might think of a sub a value in a hash with rules determining which key (and therefore sub) to pick, either at runtime or design time. Think about this (trivial) example:

sub make_binary { eval "sub { $_[0] }" }
my %op ;
$op{add} = make_binary '$_[0] + $_[1]' ; 
$op{sub} = make_binary '$_[0] - $_[1]' ;     
$op{mul} = make_binary '$_[0] * $_[1]' ; 
$op{div} = make_binary '$_[0] / $_[1]' ; 
$op{max} = make_binary '$_[0] > $_[1] ? $_[0] : $_[1]' ; 

for (sort keys %op) {
    print "2 $_ 3 = " . $op{$_}->(2,3) . "\n";
}
[download]

Kind of customization via "templating."