Java Code Refactoring

I recently browsed again the excellent book Code Complete from Steve McConnell while in the middle of several Java code reviews. Although the book is nor specifically dedicated to Java code, I still found it quite useful and inspiring.

The chapter on refactoring in particular offers a very practical perspective that all programmer should have in mind when it comes to infuse a dose of evolution in the life cycle of their software.

What I found particularly valuable are the checklists that the author has put together: reasons to refactor, specific re-factorings (data level, statement level, routine-level, class-implementation, class-interface, system-level), refactoring safely, strategies, summary.

Since I do not have time to comment every item in these checklists, I decided to pick-up those that are not trivial or obvious and might bring the best return on your refactoring investment.

In a future post, I would like to illustrate some of these refactoring techniques with java code snippets, but that will be later :)

Checklist: Reasons to Refactor

• Code is duplicate
• A routine is too long
• A loop is too long or too deeply nested
• A class/interface/method has poor cohesion ⇐
• A class interface does not provide a consistent level of abstraction ⇐
• A parameter list has too many parameters ⇐
• Changes within a class tend to be compartmentalized
• Changes require parallel modifications to multiple classes ⇐
• Inheritance hierarchies have to be modified in parallel
• Related data items that are used together are not organized into classes ⇐
• A routine uses more features of another class than of its own class
• A primitive data type is overloaded
• A class doesn't do very much
• A chain of routines passes tramp data ⇐
• A middle man object isn't doing anything
• One class is overly intimate with another
• A routine has a poor name
• Data members are public
• A subclass uses only a small percentage of its parents' routines
• Comments are used to explain difficult code
• Global variables are used
• A routine uses setup code before a routine call or takedown code after a routine call
• A program contains code that seems like it might be needed someday

Checklist: Summary of Refactorings

• Data Level Refactoring
• Replace a magic number with a named constant ⇐
• Rename a variable with a clearer or more informative name
• Move an expression inline
• Replace an expression with a routine
• Introduce an intermediate variable
• Convert a multi-use variable to a multiple single-use variables ⇐
• Use a local variable for local purposes rather than a parameter
• Convert a data primitive to a class
• Convert a set of type codes to a class
• Convert a set of type codes to a class with subclasses
• Change an array to an object
• Encapsulate a collection ⇐
• Replace a traditional record with a data class
• Statement Level Refactorings
• Decompose a boolean expression
• Move a complex boolean expression into a well-named boolean function
• Consolidate fragments that are duplicated within different parts of a conditional
• Use break or return instead of a loop control variable
• Return as soon as you know the answer instead of assigning a return value within nested if-then-else statements
• Replace conditionals with polymorphism (especially repeated case statements) ⇐
• Create and use null objects instead of testing for null values
• Routine Level Refactorings
• Extract a routine
• Move a routine's code inline
• Convert a long routine to a class
• Substitute a simple algorithm for a complex algorithm
• Add a parameter
• Remove a parameter
• Separate query operations from modification operations
• Combine similar routines by parameterizing them
• Separate routines whose behavior depends on parameters passed in ⇐
• Pass a whole object rather than specific fields
• Pass specific fields rather than a whole object
• Encapsulate downcasting ⇐ 

Class Implementation Refactorings

• Change value objects to reference objects
• Change reference objects to value objects
• Replace virtual routines with data initialization
• Change member routine or data placement
• Extract specialized code into a subclass ⇐
• Combine similar code into a superclass
• Class Interface Refactorings
• Move a routine to another class
• Convert one class to two
• Eliminate a class
• Hide a delegate ⇐
• Replace inheritance with delegation
• Replace delegation with inheritance
• Remove a middle man ⇐
• Introduce a foreign routine
• Introduce a class extension
• Encapsulate an exposed member variable
• Remove Set() routines for fields that cannot be changed
• Hide routines that are not intended to be used outside the class
• Encapsulate unused routines ⇐
• Collapse a superclass and subclass if their implementations are very similar
• System Level Refactorings
• Duplicate data you can't control ⇐
• Change unidirectional class association to bidirectional class association
• Change bidirectional class association to unidirectional class association
• Provide a factory routine rather than a simple constructor
• Replace error codes with exceptions or vice versa