Refactoring Perl #4 - Replace Temp with Query

[agianni]

< #3 - Inline Temp

Series Index

#5 - Introduce Explaining Variable>

You are using a temporary variable to hold the results of an expression.

Extract the expression into a method. Replace all references to the temp with the new method. The new method can then be used in other methods.

(Fowler, p. 120)

The following examples follow Fowler's, although I use the ternary operator, as this is a perfect example of when to use it. Here's how the refactoring looks:

sub get_price{
    my $self = shift;

    my $base_price = $self->{_quantity} * $self->{_item_price};
    my $discount_factor = $base_price > 1000 ? 0.95 : 0.98;

    return $base_price * $discount_factor;
}

becomes:

sub get_price{
    my $self = shift;
    return $self->base_price() * $self->discount_factor();
}

sub base_price{
    my $self = shift;
    return $self->{_quantity} * $self->{_item_price};
}

sub discount_factor{
    my $self = shift;
    return $self->base_price > 1000 ? 0.95 : 0.98;
}

Get the code

Fowler suggests that that this is "often a vital step before Extract Method" (Fowler, p. 120), which is probably when I have found my self using this technique most often -- unwittingly until now.

This particular example seems a little simplistic at first blush. Generally, I find this to be more important when I am trying to refactor one large method into a few smaller methods, each of which needs access to what was once a local variable. Often I have done this by declaring the local variable in the main method and passing it to each of the refactored methods instead of refactoring it as a query method. Sometimes that the only option when working with a procedural programming language, like non-OO Perl.

The need to extract queries in this particular case doesn't seem that strong given the single use of the queries. That said, as I suggested in Inline Method, this example extracts what are essentially business rules for the greater application. In this case, these are rules that are generally referred to as enumerators, defining how discounts are applied and how a total price is calculated. I find that it can be very useful to keep these business rules separate from the logic that defines the behavior of the application itself. I would likely put these extracted queries into their own class for business rules.

[mr_mischief]

Other than switching to something more OOish with fewer direct values accesses and more method calls, I fail to see what this example accomplishes.

The cons, though, are clear to me. You're using more vertical space in the editor. You're making more context switches. You're using more overall code, so there are more places for bug to get in (although the code is really simple).

Earlier in this series you posted a node about Fowler saying to replace temporary variables with inline expressions or something similar, didn't you? How's this:

sub get_price{
    my $self = shift;

    return (
        ( $self->{_quantity} * $self->{_item_price} ) > 1000
        ? ( $self->{_quantity} * $self->{_item_price} ) * 0.95
        : ( $self->{_quantity} * $self->{_item_price} ) * 0.98
    );
}


Of course, that's less legible, more bug prone, and trades one scalar (the memory for which could be reused once this little snippet goes out of scope) for having to recalculate the value twice, but it follows guru advice.

If you just do away with one of the two temps and use a more powerful operator, though:

sub get_price{
    my $self = shift;

    my $base_price = $self->{_quantity} * $self->{_item_price};
    return $base_price *= $self->{_quantity} > 1000  ? 0.95 : 0.98;
}


That seems to me to be about the best compromise. You get rid of half your temporary values, it's still just one method, it's short, it's clear, and it's idiomatic.

Of course, there's still the small matter of three magic numbers, but for the example we can probably overlook that.

[agianni]

I certainly don't advocate for refactoring or following any particular guru advice merely for the sake of doing so. You are absolutely right that this example may appear unnecessary or counterproductive. If you found this to be the case in a particular example you ran into in the real world, I would expect that you would not choose to refactor.

Fowler discusses the upsides and downsides of refactoring in the early chapters of the book. If you find yourself interested in the details then, by all means, pick up a copy. Otherwise, please take these examples with a grain of salt.

This example may not be so good in part because it lacks context. As I mentioned in the OP, something like value of the $base_price temp variable is likely to be used in a number of different places in your code. As such, refactoring the definition of the base price actually limits rather than raises the potential for introduction of bugs by defining what base price means in one place. Again, context is the key, and the lack of context in some of these examples will undoubtedly cause confusion at times.

The upshot is that my goal here is to start with Fowler's examples and work from them. There will undoubtedly be cases where the examples don't necessarily translate well. This may be, in part, because I am converting examples in Java, where OO isn't a choice, to Perl, where it is. Or, it may be that an example that works well in Java doesn't work so well in Perl, despite the validity of the refactoing pattern. As such, issues like these will likely arise.

I am posting these examples to PerlMonks expressly to encourage discussion. So please don't take this reply (mine) as an admonition for silence. I would simply ask that y'all keep an open mind about it, take the examples with a grain of salt and keep the conversation going. I'm happy to be participating in this conversation about OO techniques in Perl.

[mr_mischief]

I don't doubt that in certain circumstances Fowler has found this to be a worthwhile reason for refactoring some code.

My issue with the example is that it is much simpler than the code that likely called for the refactoring in question. Case studies are nearly always favorable to contrived and overly simplistic examples, but that is just my opinion. In this particular case, though, I think the contrived example Fowler provided was too simple and would, in many places, be used as a counterexample.

As you've assured me that you're not stating these exercises as absolutes, let me assure you that I don't mean to discredit the examples entirely. I'm just pointing out where I think they are flawed and where I think Perl could be used in a more Perlish way.

As for the base price being factored out separately to remove bugs, unless the base price changes often, I'd rather see it spelled as:

$self->{'_hase_price'};


if that's a concern. The base price (extended price before discount) is not going to change any more often than the quantity of units or the price per unit, which were both considered to be object data directly. In fact, the base price would change if either of those did. Again, this is a weakness of the example itself and not of the point the example was used to make or your post.

[shmem]

Neither of your to-be-refactored and refactored code parses under Perl 4.

What am I missing?

[agianni]

That is refactoring Perl 4, as in the latest in a series, not refactoring version 4 of the Perl language. Sorry if that was confusing. Many of these examples are explicitly object oriented, so obviously they won't parse under Perl 4 or earlier.

[shmem]

That is refactoring Perl 4, as in the latest in a series

I'm looking forward to "refactoring Perl 6" :-P

My previous post has been a (unfunny?) hint at the title being misleading. IMHO the dash is misplaced, and saying "refactoring Perl - 4. Replace Temp with Query" would avoid that type of "confusion" :-)

[akho]

I may be missing something, but will you not need a temporary variable anyway in all but the simplest cases just for efficiency through memoization?

[agianni]

I don't usually use temp variables for that, but that's the idea, if you mean something like:

sub base_price{
    my $self = shift;

    if ( not $self->{_base_price} ){
        $self->{_base_price}
            =  $self->{_quantity} * $self->{_item_price};
    }
    return $self->{_base_price};
}

That's how I usually do result caching for methods. There are other options too, like Memoize, although I haven't tried any of the modules that do this.

[akho]

Won't work if $self->{_item_price} changes.

Of course abstracting such things away is the right way to go; but you still often need temp variables. So this refactoring technique should probably be promoted as "do what common sense tells you", not as "remove temp vars".

Memoize is a good thing too, btw. Even better with Memoize::Attrs.