Extract Method Pattern:

	- take care with local variables (unmodified vars can easily be made parameters while modified
	parameters need TLC)
Ooops, the tests broke after the last refactor.  Fix typo in amountFor return type.
Move Method Patter:

	- generally, methods should act on data within their class: in this example, amountFor acts solely
	on data in Rental and not on data in Customer; therefore, move amountFor to the Rental class

	- we rename the method to the more meaningful name, getCharge, and simply delegate from the
	old amountFor to the new getCharge
Move Method Part 2:

	- If a delegating method is public, it is usually a good idea to leave it so as not to break
	existing clients; in this case, the delegating method is private, so let's just call the
	getCharge directly.
Replace Temp with Query Pattern:

	- if there is a temporary variable that is set and not subsequently changed, it is
	redundant and can be removed

There are a few reasons to remove temporary variables:
	- they can cause lots of parameters to be passed around
	- they are easily to lose track of (especially in long methods)

NB: of course, there is a performance price to pay (here charge is calculated twice); however,
it is very important to separate refactoring and optimizing.  Always refactor _first_ to make
code readable, manageable, maintainable etc; then optimize.
Extract Method, Move Method and Replace Temp:

	- calculating frequent renter points is a good candidate to fly solo (extract method)
	- hmmm ... it also seems like it acts mostly on Rental data (move method)
	- ok, cool: we don't really need the frequentRenterPoints temp variable in the newly
	extracted and moved method

	- (p.s. we don't need that extra result line since groovy methods will return the last
	value)
Replace Temp with Query Pattern:

	- What is the biggest drawback of temporary variables?  They are only useful to the enclosing
	method.  In this commit, we refactor the two temporary variables into queries.  There are
	two really nice side effects of this:

		1) the two new methods are now available to other methods
		2) look at the statement method!  it only does ONE thing now: it creates a statement result
		string, and that is all it does

Two notes here:

	1) Groovy has some really nice "Syntactic Sugar" (Martin Odersky's lovely expression of Scala's
	niceties) that allow us to write getTotalCharge() and getTotalFrequentRenterPoints() in a
	functional way without temporary variables
	2) It seems _VERY_ odd to refactor the code so that where there was one loop, there are now
	three loops.  Lots of developers would not do this refactor for this point.  I have COUNTLESS
	times advocated for code changes in reviews exactly opposite to this because I thought I was
	being clever in optimizing the code being review.  Fowler advocates refactoring FIRST and
	optimizing second for two reasons (a) they are truly distinct processes and (b) optimizing
	properly refactored code gives you _many_ more options for optimization.  Additionally,
	we often think we need to optimize code without profiling, that is really knowing how much
	impact the code has on overall performance.
Added a few spaces after quote; Added how to use
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.