in reply to Re^2: Refactoring Perl 4 - Replace Temp with Query
in thread Refactoring Perl #4 - Replace Temp with Query

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.

Replies are listed 'Best First'.
Re^4: Refactoring Perl 4 - Replace Temp with Query
by jdporter (Paladin) on Aug 02, 2007 at 18:34 UTC

    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
      I have no issue with examples being simplified (although my personal preference is for actual case studies). I only have an issue with examples being oversimplified, in which the example serves to make the technique look harmful rather than helpful.

      The particular example not only leads to the technique appearing to be overkill, which most simplified examples will. It actually leads to the particular code of the example being, IMHO, less expressive and more prone to bugs after use of the technique than before. That surely will not build confidence in the technique.

      I think that examples should, when possible, probably serve to show not just the How, but also the Why. I think this choice of example on Fowler's part does not show why to use the technique in question. That's nothing against agianni's repetition of the example here, since the point of this series of nodes on agianni's part is to go through the exercises in order as Fowler presented them and show how they may apply in Perl.