Re^2: Refactoring Perl 4 - Replace Temp with Query

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]

Comment on Re^2: Refactoring Perl 4 - Replace Temp with Query Select or Download Code

Replies are listed 'Best First'.
Re^3: Refactoring Perl 4 - Replace Temp with Query by mr_mischief (Monsignor) on Jul 31, 2007 at 18:58 UTC
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]
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	[reply]
Re^5: Refactoring Perl 4 - Replace Temp with Query by mr_mischief (Monsignor) on Aug 02, 2007 at 18:51 UTC
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.	[reply]