dcpatton

Refactoring is the process of changing software such that it does not alter the functional behavior of the code while improving the internal structure. The first key point is that code which is already written is being improved. The second key point is that the behavior of the software is not being altered. This is not a process for fixing bugs. I’ve previously discussed motivations for refactoring in Why Refactor.

Below are 5 refactorings that I frequently use in practice:

1. Extract Method

   One of the most common refactorings I use. It involves taking a section of code and putting it into a method whose name explains the purpose of the method. This has two advantages for me. First, it breaks up longer methods into shorter, clearer methods to read. Second, it is useful for applying the DRY principle when you have the same code repeatedly in a class or multiple classes. You may need to determine how to make code sections look exactly alike so that this can be done. For example, passing in nulls to the method in certain classes, but not in others. I believe this is an example of Parameterize Method

2. Rename Method

   This is the process of changing a method name such that the name is more informative by clearly showing the purpose of the method. I often perform this refactoring when introducing another new method to the same class which is similarly named.

3. Move Method

   Another common refactoring for me. I use this when I want better cohesion in my classes. This leads to simpler designs and better understanding of the responsibilities.

4. Introduce Parameter Object

   I introduce a new data object (with getters and setters) when I have a group of parameters that are related and frequently accessed together. This then may lead to use of Move Method if there is also associated behavior with these parameters.

5. Introduce Explaining Variable

   This is one that I wish I used more often. I think the best examples I have seen are to introduce a boolean for a complex expression in an if statement. By using a name that adds clarity, reading the if statement can be improved substantially. For super complex conditional logic expressions you can reuse this repeatedly to simplify the code. It can really make code maintenance much simpler in the future.

Agile methodologies make refactoring an enjoyable process. With the principles of test-first design and simple design, refactoring becomes a complementary exercise. It makes it easier to keep the design simple and the unit tests provide the confidence needed to make frequent changes to the code during refactoring sessions. Perform your favorite refactoring and run the tests to be sure no functional behavior was broken.

What are your favorite refactorings? For more insight into refactoring, I highly recommend Refactoring: Improving the Design of Existing Code (Amazon Affiliate link) by Martin Fowler.