Fall Semester 2005: September 8, 2005 - December 12, 2005
Out on:
September 30, 2005
Due by:
October 5, 2005 by 5:59 pm for full credit (11:59 pm for 10% off, hard deadline)
Collaboration:
None
Grading:
Packaging 10%, Style 10%, Performance 10%, Design 20%, Functionality 50%
The fourth assignment for
600.226: Data Structures
deals mostly with lists and their applications.
There are again some "written" problems, to be answered in the
README file.
Your first task for this assignment is to implement a
generic list NodeList as outlined in lecture.
The archive below contains a number of interfaces and
exceptions that you will need for your list class.
As is to be expected, NodeList has to implement
the PositionList interface we provide.
You have to implement the Position and
Iterator interfaces as well, and the classes
you write for this purpose should both be nested
inside your NodeList class.
You should provide a toString() method in addition
to those defined in the PositionList interface.
A new list into which 1, 2, and 3 were inserted using
insertBack() should print as
[1, 2, 3] while an empty list should print
as [].
Your NodeList class should also have a
main method that performs basic unit testing for
your implementation.
Be sure to test all methods, including the
behavior of forward and backward
iterators.
Also, be sure to test that the correct exceptions are thrown
in error situations.
Here are the necessary interfaces and exception classes: lists.tar.gz
Your second task is to provide a critique of the interfaces
we defined for lists.
Feel free to use other designs you know about (for example
from the Java class libraries, from the text book, from
libraries of other languages you know, etc.) to inform your
critique.
One especially strange problem has to do with the way the
Iterator interface is defined. I don't want
to give too much away, but think about what it is
compatible with and where it can thus be passed.
But don't focus exclusively on that issue...
Your critique should go into your README file.
We won't be hurt if you "diss" our design, just be sure
that you're making a good case that you can back it up.
Please turn in a
gzip
compressed
tarball
of your assignment (the extension should be .tar.gz).
The tarball should uncompress into a directory
cs226-assignment-4-login
with login replaced by your Unix login name
(so I would use cs226-assignment-4-phf);
uncompressing should not create any other files
in the current directory.
The tarball should contain no derived files whatsoever
(i.e. no .class files, no .html files, etc.),
but allow building all derived files.
Include a README file that briefly explains what your
programs do and contains any other notes you want us to check out
before grading (and of course your answers to "written" problems).
For reference, here is a short explanation of the grading criteria.
Packaging refers to the proper organization of the
stuff you hand in, following the guidelines for Deliverables above.
Style refers to Java programming style, including
things like consistent indentation, appropriate identifiers,
useful comments, suitable javadoc documentation, etc.
Simple, clean, readable code is what you should be aiming for.
Performance refers to how fast your program can
produce the required results compared to other submissions.
Design refers to proper modularization and the
proper choice of algorithms and data structures.
Functionality refers to your programs being
able to do what they should according to the specification
given above; if the specification is ambiguous and you had
to make a certain choice, defend that choice in your
README file.
If your programs cannot be built you will get no points whatsoever.
If your programs cannot be built without warnings using
javac -Xlint
we will take off 10% (except if you document a very good reason).
If your programs fail miserably even once,
i.e. terminate with an exception of any kind,
we will take off 10%.
Not much of a bonus problem this week, but if you feel like it,
write an adapter class that uses your NodeList to
implement the UnboundedStack interface from last
week.