in reply to Refactoring Perl #4 - Replace Temp with Query

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
    );
}

[download]

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;
}

[download]

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.

Replies are listed 'Best First'.
Re^2: Refactoring Perl 4 - Replace Temp with Query
by agianni (Hermit) on Jul 31, 2007 at 13:00 UTC

    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. 

    perl -e 'split//,q{john hurl, pest caretaker}and(map{print @_[$_]}(joi
+n(q{},map{sprintf(qq{%010u},$_)}(2**2*307*4993,5*101*641*5261,7*59*79
+*36997,13*17*71*45131,3**2*67*89*167*181))=~/\d{2}/g));'

    [download]
[reply]
[d/l]
[select]
      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'};

      [download]

      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.
[reply]
[d/l]

        The reader must always keep in mind that the examples are given only to show the technique, not to serve as illustrative cases. In other words, for pedagogical purposes, this 10-line code fragment is the picture which, lacking it, would take 1000 words of prose to explain. Once the reader has learned how the technique works, she can implement it in real-world cases which are much more complex and actually call for the pattern.

        A word spoken in Mind will reach its own level, in the objective world, by its own weight
[reply]

In Section Meditations