We want to have autonomy, freedom. Before we achieve such a state, it is good we know some principles, rules – so we can try, follow, modify and wisely improve them…. (reject to follow them).
In case of refactoring to be able to perform it effectively I’ve discovered such a rule and gave it name of “Pyramid of Refactoring”. This rule allows to approach refactoring from the smallest possible transformations into more and more complex ones.
This concept is based on idea that you shouldn’t (although you can) jump into bigger refactorings, like extract new class, extract new method, before you finished dealing with clear sequential flow. Clear flow means that you are able to read and understand your code easily and quickly. This means that it doesn’t contains things like mysterious field / variable names, (deeply) nested conditions and loops. Getting rid of single exit point from your code also might reduce the number of local variables significantly.
How did I discover it? Surprisingly it has already been since the beginning. Where it is? It is BETWEEN the two most famous books about refactorings.
In case of Martin Fowler’s “Refactoring” book – each transformation can be placed somewhere higher or lower within the pyramid. For example extract parameter goes into method-level, move method into level of classes. But inline or extract variable would be put into the bottom level of flow. Extract interface or pull (template) method up into base class allows to think in terms of abstractions / patterns level.
The second book by Joshua Kerievsky (“Refactoring to Patterns”) takes the subject of refactoring such further. It is a continuation of Martin Fowler’s above book. It contains lots of refactorings into some design patterns. Each of these samples can be broken down into set of transformations that goes from the bottom of the pyramid towards its top.
In my next blog I will take Joshua’s refactoring into Interpreter Design Pattern and present how these refactoring steps are placed within the pyramid.