Thoughts
--------
Should the robot methods be public protected or private? who can
access them? the random robot needs to certainly. would the outside
world be able to control the robot too? would this interfere with escaping? 

Should the goForwards() method check for walls and do something
appropriate or should it assume someone else watches out for the
walls? Which is a safer way to design it? Any such decisions should
appear in the goForward() comments. 

All robots start with three possible moves
  - turn left but don't move to a new space
  - turn right but don't move to a new space
  - if there is no wall in the way, go forwards one space
The right hand robot adds one more move
  - go around the corner

Perhaps all robots need an escape method. it would make repeated moves
using the escape strategy for the robot unless it wins freedom or dies
of old age. The Robot class has no escape strategy so it can't really
come with code to escape. Each subclass needs such a method. What can
you put in the Robot class so that nobody can make just a Robot and
all subclasses are forced to have an escape method? (hint: we covered
this earlier in the term).

The random robot in this assignment can make one of three moves each
turn:
  - turn left but don't move to a new space
  - turn right but don't move to a new space
  - if there is no wall in the way, go forwards one space
Make sure your algorithm matches this. Many groups have an incorrect
or more complex algorithm.

Remember
---------
everything needs to be labeled public/private/prot.
You should start out with everything private and make changes only as
you find you need them.

use a consistent naming strategy for methods and member data
typically these start with a lower case letter. Classes start with 
an upper case letter. constants (final) are in all caps. Do not name 
things with a bunch of letters. TIVHTR (This is very hard to read).

Tech specs and User manuals
----------------------------
Both can be created via Javadoc. 

A user's manual is created with the public feature of Javadoc.
The main stuff in your user manual should be a comment at the 
top of the outer class. The program purpose goes there too.
Any public stuff needs a comment explaining 
what a programmer would do with it. Public stuff should not expose
details of implementation. For example: do they really need to know
you used an array to hold the maze? If you expect a programmer to 
extend your software, then use the protected mode of Javadoc.
(Note: when we cover the official way to measure program speed, you
might want to tell the user how fast a method is but NOT how you
implemented it). 

A tech spec is create with the private feature of Javadoc.
It does expose ALL the implementation and design details. Your
important algorithms should be here on top of the methods that
implement them. all of the private methods and data need those
decisions you put into the design phase. 

This means that you can actually go straight from CRC to Javadoc
and not type things multiple times. Simply write a class with no
implementation but a whole lot of comments. 

If you specify that the User Manual portion of Javadoc goes into
a UserManual directory and the tech spec goes into a TechSpec
directory, you get both easily updated and all you have to do is keep
your .java files current.

A helping start with test cases
-------------------------------
Test Data		What's being tested		Expected Results
-------------------------------------------------------------------
right hand		hand on right wall		at all times
							there is a
							wall to his
							right

(this does NOT also imply he finds an exit or moves at all, 
 one thing at a time)

every robot		robot movement			in one move, the
							robot will do one of
							- turn right
							- turn left
							- go 1 square
							forwards if no
							hedge in way 

(this restricted set of movement does not allow for wall hopping 
 or teleportation it's easier to restrict what he does do than to 
 list what he doesnt do)