General principles, patterns – at one side allow us to tidy up knowledge, use common approach when solving certain kind of problems. On the other side they might impede our creativity and inspiration. But even then we have something we can base on even if we want to reject it and invent something better.
In case of refactoring to be able to perform it effectively I’ve discovered such a principle 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? During the last 7-8 years I’ve conducted over 100 workshops about refactoring. They were always using concepts from two core books about refactoring. First book by Martin Fowler was always like a catalogue to me. The second one “Refactoring to Patterns” by Joshua Kerievsky was always a kind of “guidelines” book with steps to follow when going from current legacy code towards expected design pattern. The concept of Refactoring Pyramid is placed between and also visible inside each of these books… although such a name is not used anywhere
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 begins the level of classes. But inline or extract variable would be put into the lowest (but basic!) level called level of flow. Extract base class that contains template method allows to think in terms of abstractions / patterns level. Similar case applies to extracting interface to hide a class behind pattern of command or factory.
The second book by Joshua Kerievsky (“Refactoring to Patterns”) takes the subject of refactoring much further. It is a continuation of Martin’s 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.
For example in order to extract command design pattern, we start with extracting parts of switch / if-else statements into smaller methods (of lower level of abstractions). Next we put each of these methods into a new class, later extract an interface that is implemented by each such an extracted class. Finally the main classe delegates to command classes hidden behind the abstraction of an interface.
In my next blog Pyramid of Refactoring – Example I will take Joshua’s refactoring into Interpreter Design Pattern and present how these refactoring steps are placed within the pyramid.