From: Garrett Mitchener <wgm2@duke.edu>
  To  : 
  Date: 27 Apr 1999 21:54:58 -0400

A note about graphs

Someone sent me email:

my group designed our adventure game somewhat different than what has
been suggested.  our graphnode class doesn't have any sense of a
"connection" at all, but rather just references to other graphnodes
that it can connect to.  null links represent impassible areas.  the
plan, for now, is to have a vector in each GraphNode that holds all
the maze objects that are present in that particular node.  each
object would be responsible for adding or removing itself from this
vector, and looking through the vector to determine interactions.  we
thought this was a much more natural implementation- as long as why we
made this decision is well documented, will it be entirely acceptable
from a grading standpoint?  thanks.

----------

I've looked at one version of their code which I hope is the right
one, and their Graph is a two-dimensional array of GraphNode objects,
each of which has five links (north, south, east, west, and teleport)
which are direct references to other GraphNode objects.  From what I
can tell, this was meant to be a "friend" class to Graph.  I have the
following comments on their design:

* The matrix gives you a sense of space and location.  That's fine.

* There is nothing stopping you from making connections that have
  nothing to do with the sense of space.  You can link any GraphNode
  to any other GraphNode in any direction.  Given that, there's no
  reason to limit yourself to five links, or to bind them to
  particular directions.

* You can have only two kinds of connection: there or not there.  This
  means you can't easily have locked doors, and apparently there is
  only space for one teleporter in a given room.  For example, you
  can't have a maze of teleporters or a single teleporter that sends
  you to different places depending on what number you punch in.

* You have to keep checking whether things are null or not.

I suspect, although I can't say for sure, that these issues complicate
the rest of your code.  As far as evaluation is concerned, I think
this is a very serious issue.  I brought it up at the UTA meeting, and
Duvall said that if this Graph class is producing spaghetti code and
lots of instanceof's and other type checks, it will lower your grade.
If you don't have that problem, it won't.

In other words, if you have stuff like this:

if( gn.north != null )
{
  if( gn.north.isFoo() )
  {
  ..
  }
  else if( gn.north.isBar() )
  {
  ...
  }
...
}
if( gn.south != null )
{
...
}
if( gn.teleporter != null )
{
...
}

etc. all through your code, then you need to fix it up, so that you
can say this kind of thing instead:

Enumeration e = gn.getConnections();

while( e.hasMoreElements() )
{
  ((Connection)e.getNextElement()).doSomething();
}

Remember: Spaghetti code is bad!  When you have what I described
above, it means some class is doing too much of the work and should
pass the buck to some other class.

Also, just looking at how your GraphNode is implemented, you could get
rid of all those switch() statements with an array or vector or map,
which would make it simpler and more powerful at the same time.

I know you wanted a plain "yes" or "no", but it's just not that
simple.  If you can look at your code and how the graph is used and
honestly say that it isn't making things complicated and
spaghettified, then leave it in.  If you really need connection
classes of some kind and you've got functionality for them strewn all
over the place in if-else chains, then you need to put other stuff on
hold and fix your design.

	Hope this helps,
	-- The Exorcist