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.
Pyramid of Refactoring
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. I placed the concept of Refactoring Pyramid between these books… Suprisingly I haven’t found such a name anywhere yet.
Refactoring (Book) – takeaways
In case of Martin Fowler’s “Refactoring” book – I can put each transformation somewhere higher or lower within the pyramid. For example extract parameter goes into method-level, move method begins the level of classes. Inline or extract variable goes 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.
Refactoring to Patterns (Book) – takeaways
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. You can break each of these samples 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 these methods implement. Finally the main classe delegates to command classes hidden behind the abstraction of an interface.
In my next blog How to clean code according to refactoring pyramid? I will take Joshua’s refactoring into Interpreter Design Pattern and present how these refactoring steps are placed within the pyramid.
