Since I have been posting some of my favorite refactorings (5 Great Code Refactorings) and re-reading Refactoring
- Move Method
- Replace Magic Number with Symbolic Constant
- Encapsulate Collection
- Introduce Null Object
- Replace Nested Conditional with Guard Clauses
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.
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.
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.
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.
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?
