dcpatton

Since I have been posting some of my favorite refactorings (5 Great Code Refactorings) and re-reading Refactoring by Martin Fowler lately, I thought I would discuss five refactorings that I wish I used more.

1. Move Method

While I use this refactoring on a regular basis, I’d like to use it more in a specific case. Specifically I want to move more behavior into my data classes so that they don’t just contain simple get and set methods and private fields. It may even be possible to make the get and set methods private at some point. By using this refactoring in the specific case of data classes, I believe that my classes will have improved cohesion in the OOD sense.

2. Replace Magic Number with Symbolic Constant

I also use this on a regular basis when I am coding. For example, I might use the literal 1024 several times within a class. I usually will replace it with a constant that explains what it is so I only need to change it in one place. This is fine. However, I resolve to replace some magic numbers with a constant even if they are only used a single time. The reason for this is that by naming the constant appropriately, I can achieve improved readability for my code.

3. Encapsulate Collection

This is a refactoring that I have never used and resolve to try this year. The idea is to refactor a class containing a method that returns a modifiable collection into a class with a method that returns a read-only collection and has add and remove methods for the collection. In Java, this is done by using the Collections interface methods unmodifiableList(), unmodifiableSet(), etc. This produces proper encapsulation and leaves the responsibility for manipulating the values of the collection up to the class which owns the collection. Thus the coupling is now similar to that of a data class with get and set on non-collection objects.

4. Introduce Null Object

This is one of my favorite refactorings. I saw it presented at a user’s group meeting many years ago in a discussion of the null object pattern. The basic idea is to replace repeated checks for a null value with a null object. Normally you test if an object is not null and then call a method on the object. Instead of doing that you can create a null object and then call the method and get the appropriate behavior. The refactoring involves creating a null object (a subclass of the same type as the non-null object) which contains the methods needed to produce the same behavior in your code as would be done when the test of the null value for the object is true. I infrequently use this refactoring and resolve to use it much more this year. One of the biggest motivations is when looping through objects for display purposes. I can eliminate all those tests for null values that just lead to displaying blanks.

5. Replace Nested Conditional with Guard Clauses

I’ll give a very simple example of this here:
if (i==1) { result=odd1; } else if (i==2) { result=odd2; } else if (i==3) { result=odd3; } else { result=normal; } return result can be refactored to if (i==1) return odd1; if (i==2) return odd2; if (i==3) return odd3; return normal;
The above method reflects the unusual case where i equals 1,2, or 3. It “guards” against them. This refactoring provides more clarity within the code and I resolve to use it more.

If you have any questions about how to perform the above refactorings, I encourage you to leave them in your comments here and also I highly recommend picking up a copy of Refactoring.

I believe that each of these refactorings will contribute to better code quality based on Why Refactor. What are your favorite refactorings?

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.