Monthly Archives: December 2014

Refactoring helps you develop code more quickly

Refactoring is something you do all the time in little bursts. You don’t decide to refactor, you refactor because you want to do something else, and refactoring helps you do that other thing.

The Rule of Three
The third time you do something similar, your refactor

Refactor when you add a function/feature
Whenever I have to think to understand what the code is doing, I ask myself if I can refactor the code to make that understanding more immediately apparent.

A nice read to enforce your conviction to use Refactoring

Refactoring Design
In Chapter 2 Refactoring seems to be presented as a solution to thinking the upfront “best design”, kind of like if it was the perfect detergent for a stain.

What I think the use of Refactoring is kind of a natural evolution of a developer. As beginners we stress out on our first architecture /design, then you evolve a bit and consider that sometimes it is easier to just begin developing instead of sitting for weeks in front of blank paper, yes you might get stuck with the crappy first design on this project. But on the next step you will be almost Refactoring without doing a conscious exercise.
And then learn techniques to refactor

By: Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts

Chapter 1:
Decomposing and redistributing methods:
– locate modified local variables, if there is only one, extract it to a separate method and return it.
– A method should be on the object whose data it uses. E.g: “amount calculation only uses information of the Rental, methods should not be under Customer but under Rental”
– local/temp/auxiliar variables are often a problem in that they cause a lot of parameters to be passed around when they don’t have to be. Easily lose track of what they are there for.
– Get rid of local variables that are assigned as result of an extracted/refactored method. Performance might be affected, but that is another step outside the refactoring process. Optimisation is much easier done with a refactored code.
– Replace temp/local variables with “Query”-> replace with private helper methods (which could end up being public easily)
– Replace conditional logic with Polymorphism. “It is a bad idea to do a switch based on an attribute of another object. If you must use a switch statement, it should be on your own data, not on someone else’s”
– If inheritance is not an option, you need the object to change class during its lifetime (New Release Movie can change to Regular Movie during the lifetime) -> Strategy or State pattern.
– Strategy or State pattern a very similar, to differentiate them ask question: Does the class represent an algorithm for calculating or does it represent a state?.

Strategy pattern – Wikipedia:

enables an algorithm’s behavior to be selected at runtime
– defines a family of algorithms,
– encapsulates each algorithm, and
– makes the algorithms interchangeable within that family.
For instance, a class that performs validation on incoming data may use a strategy pattern to select a validation algorithm based on the type of data, the source of the data, user choice, or other discriminating factors. These factors are not known for each case until run-time, and may require radically different validation to be performed.