Refactoring through abstraction
-------------------------------
In the real world, either code is improved or it dies.
Many improvements relate somehow to code quality.
The process of improving code structure without
giving up functionality is called *refactoring*.
"Refactoring" is a good word to know for phone screenings and job
interviews.


 6. The final problem on this homework is to *create a function*
    `nearest-point-refactored`, which is a simplified version of your
    `nearest-point` function.  Your goal is to use local functions to
    squeeze out as much repetition as possible.
    Using the abstraction and simplification techniques
    from [Section 21 (Designing Abstractions from
    Examples)](http://htdp.org/2003-09-26/Book/curriculum-Z-H-27.html#node_chap_21)
    to merge similar expressions by introducing local functions with parameters.
    
    The main opportunity for simplification is that the codes for
    vertical and horizontal boundaries should look very similar:

      - For a vertical boundary, you will identify the near and far
        sides conditional on the results of comparing the `x`
        coordinate of the query with the `x` coordinate of the
        boundary.  The near and far subtrees are determined by
        comparing the `x` coordinate with the location of the
        boundary line.

      - For a horizontal boundary, you will identify the near and far
        sides conditional on the results of comparing the `y`
        coordinate of the query with the `y` coordinate of the
        boundary. The near and far subtrees are determined by
        comparing the `y` coordinate with the location of the
        boundary line.

    To  abstract over these computations, you can pass actual
    boundary locations and subtrees, or you can pass *functions* that
    compute locations and subtrees.  Or you can use a combination.

    **How we will evaluate this problem**:

    A.  We will look to see if each helper function has a purpose
        statement that we find simple and easy to understand.

    A.  We will check to see that each helper function is limited to a
        reasonable number of parameters.  Four or five parameters is
        about the maximum that we can easily understand.

        (A good technique for reducing the number of parameters a
        function needs is to make that function `local`.)

    A.  We will check to see that no helper function has more than one
        conditional.

    A.  In each conditional, we will look to see if we can easily
        understand the questions.

    A.  In each conditional, we will look to see if we can easily
        understand the answers.  It is always easy for us to
        understand a call to a helper function, provided that we
        understand its purpose statement.

    A.  We will look to see that your simplified function passes all
        the same tests as your original function.   This means we
        expect you to include *both* sets of tests.