How easy is it to add _new_ functionality refactoring?

The answer is wicked easy (yes, I'm from Massachusetts).

	- A customer wants the statement printed in HTML.  Adding this to Customer is now really easy
	thanks to all of the refactoring we did.  The only responsibility of the new htmlStatement
	method is to construct an HTML string.  Thanks to the "Replace Temp with Query" refactor,
	we don't have to even worry about temp variables.

PS This commit also contains a neat refactor with GStrings (no need to use String.valueOf())
What is the first refactor after adding new functionality?

That's right: bring the unit tests up to snuff so that all code is covered.
Move Method Pattern: switch on your own data

	- Generally speaking, things that vary should be _with_ the data that varies.  In this case
	it is the Movie class that has the varying types (in this example, priceCode), so both
	getCharge and getFrequentRenterPoints belong in Movie.  Yes, we have to pass daysRented now,
	but that is a value and not a varying type.  Another way to tell this is a good refactor is
	that we have a little less . notation, the Principle of Least Knowledge states that we should
	have 1 . per value (no getRental().getMovie().getPriceCode()).
Replace Type Code with State/Strategy AND Replace Conditional with Polymorphism!

The final piece of code that stands out is the switch statement.  First, we see that there are
different types of movies.  We don't want to subclass movie directly, rather, since we notice
that the movie types are used only in the getCharge and getFrequentRenterPoints methods, we
can say that all movies regardless of type _have_ a PricingStrategy.

Then we simply create a PricingStrategy interface and an implementations of this interface
for each of the types.

The Groovy, and also the functional way, to implement the Strategy pattern is to pass closures
into the methods that need to perform calculations (think foldLeft function)
(see: http://groovy.codehaus.org/Strategy+Pattern); however, I wanted to at least have an
explicit interface rather than passing closures into the getCharge and
getFrequentRenterPoints methods.  In Groovy, I can define an interface and as its public static
fields define implementations of this interface as maps.  This may be an unconventional design
- one that doesn't quite fit the open/closed principle, but I think it is one interesting
way to Groovily implement this refactoring.