If you don't provide mutators, even for trivial fields, then you are just storing up pain for the future.
No, you fix your design so you don't need them in the first place.
In this case, I would make an "effect" object (I'm sure there is a Pattern for this). An effect stores values that can mutate other values when applied to another object.
my $employee = Employee->new( salary => 50_000 ); my $effect = Effect->new; $effect->set( salary => 1.02, '*' ); # A 2% raise $effect->set( frobnitz => 1.5, '+' ); # The frobnitz is up $employee->apply_effect( $effect );
The key here is you don't need to know for certain that a given field is implememented in Employee. The apply_effect method ignores any fields it doesn't recognize (like frobnitz). I'll give you that it is more lines of code than:
$employee->salary( $employee->salary * 1.02 );
But it is also a superior form of encapsulation.
"There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.
In reply to Re^11: Assignable Subroutines
by hardburn
in thread Assignable Subroutines
by dragonchild
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |