C SC 225 Lecture 10: Refactoring Introduction and Overview

[ previous | schedule | next ]

Refactoring Introduction and Overview

Selected Resources

• Refactoring: Improving the Design of Existing Code, Martin Fowler, Addison-Wesley, 1999.
• a.k.a. The Refactoring Book.
• www.refactoring.com, maintained by Fowler
• www.refactoring.com/catalog/ maintained by Fowler. Refactoring list, each linked to brief description with illustrative diagram and/or code.
• "Smells To Refactoring", Gene Garcia, wiki.java.net/bin/view/People/SmellsToRefactorings, 2004.
• "Refactoring Thumbnails", (refactoring shown in diagrams), Sven Gorts, www.refactoring.be/thumbnails.html, 2004-2005.
• “Agile Programming”, “peterchen” www.codeproject.com/gen/design/agileprogramming.asp, 2003.

Definitions

• From Fowler’s book
  • Refactoring (noun) : a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior
  • Refactoring (verb) : to restructure software by applying a series of refactorings without changing its observable behavior
• From www.codeproject.com essay
  • Refactoring is a fancy word for cleaning up the code
  • Refactoring means continuously improving the design and appearance of your code base in small steps confined to surveyable areas.

Why Refactor?

• Improves software design. Design structure tends to degenerate as software is extended and otherwise modified.
• Make the code easier to understand. Maintainer (it may be YOU) will thank you for it.
• Helps you find bugs.
• Fowler quote (source unknown): Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

Signs That Refactoring is Needed

• You can’t follow the code!
• Duplicated code segment in multiple methods.
• Class has lots of instance variables.
• Method has lots of parameters
• Method is long
• Method has multiple return statements
• Method has lots of local variables
• Method has SWITCH statements or IF-LADDERS
• Identifiers are not descriptive of their purpose
• Public instance variables (or otherwise excessive scope)
• In short, the code smells!

Things to Keep in Mind When Refactoring

• Do not refactor while at the same time adding a new feature or extending an existing feature! Note the phrase in the definitions above: “without changing its observable behavior”.
• Re-test early and often! Since you are not modifying “observable behavior”, e,g, functionality, you should already have a set of test cases you can use.
• Apply only one refactoring step at a time (this relates to the “often”) and make sure it works correctly before going on to the next one.
• Runtime performance will probably suffer; that’s OK. It can be tuned later if necessary. Refer to above quote about understandability.
• Refactoring is closely related to design patterns.

Refactoring Techniques

• Rename an identifier for consistency, clarity, conformance to standards. Identifier can represent a variable, class, method, whatever. Supported by editor’s search-and-replace feature.
• Convert duplicated code sequence into (at least) a helper method if duplicated within a class.
• Move functionality shared by multiple classes into a common base class. This is sometimes called refactoring by inheritance.
• Move functionality shared by multiple classes into a new helper class then give each class a component of the helper type. This is sometimes called refactoring by delegation.
• Separate independent functionality into different classes and methods. This supports cohesion (coupling’s smart cousin).
• Replace local variables with queries (calls to accessor methods), even if it makes the code run slower due to calculations performed in the accessor.
• Replace conditional logic (IF, SWITCH) with polymorphism.
• See references above and handout for lists of refactoring techniques.