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.