In this latest in the DoubleDawg series, GeePaw takes nice small steps to fix up the first place where the code ‘switches on type’. Oddly enough, we already had all the type info we needed: the legacy code had thrown it away!
The After Code for Step 3 (194)
Get the Flash Player to see this content.
The After Code for Step 4 (239)
These are a lot of fun! Interesting to see different people’s approaches to this; like you, I would have introduced duplication right after extracting processAnnotationsArray, but what I would have done is just cut and pasted right then to make two copies of processAnnotations, calling one processClass and the other processMethod. And then I could use the type information in the new cut-and-pasted methods to eliminate half of each, after which I’d end up in the same place that you did. Neat to see a slightly different route there, though.
David…
Thanks for the support. My long tenure with Josh Kerievsky is what makes me try to think of ways I can use the IDE. He is quite a master of that of skill.
+1 On the big fun. I need, like, 16 hours in C-Ville pairing with you, absorbing Refactor-Fu.
Seriously, there are less obvious meta-lessons lurking in this series about learning to see 4 chess moves ahead in the simplification. I’d like to see 4 ways to refactor processAnnotationsArray() arranged by level of sophistication. First one: dumb extractions with headlights on dim (I spend much of my refactoring time in this land). Last one, the one you did above right here, where the goal is always firmly in mind, and the steps are deftly arranged to get there requisitely.
Pat…
It’s funny you mention the seeing ahead thing. The next segment is about me trying to resist spiking up a solution. The resistance was in vain. The cool thing about real code is that it throws up real problems, not ‘labbed’ ones.