Project 2: Creepy Deques (aka Dequeues)

Projects are designed to test your mastery of course material as well as your programming skills; think of them as “take-home exams” and don’t communicate with anyone about possible solutions. This project focuses on the implementation, testing, and application of double-ended queues.

Problem 1: Hacking List Deques (25%)

Your first task is to implement a generic ListDeque class as outlined in lecture. As is to be expected, ListDeque must implement the Deque interface we provide on Piazza. Here are some additional constraints:

You must also provide a toString method in addition to the methods required by the Deque interface. The toString method will orient the front of the deque at the left and the back at the right. For example, a new deque into which 1, 2, and 3 have been inserted using insertBack should print as [1, 2, 3] whereas an empty dequeue should print as [].

Documentation

Don’t forget to add proper javadoc comments for your ListDeque class. You should not repeat documentation from the Deque interface unless your implementation of a method deviates from what is stated there.

Problem 2: Hacking Array Deques (40%)

Your second task is to implement a generic ArrayDeque class as outlined in lecture. As is to be expected, ArrayDeque must implement the Deque interface we provide on Piazza. Here are some additional constraints:

You must also provide a toString method in addition to the methods required by the Deque interface. The toString method will orient the front of the deque at the left and the back at the right. For example, a new deque into which 1, 2, and 3 have been inserted using insertBack should print as [1, 2, 3] whereas an empty dequeue should print as [].

Documentation

Don’t forget to add proper javadoc comments for your ArrayDeque class. You should not repeat documentation from the Deque interface unless your implementation of a method deviates from what is stated there.

Problem 3: Testing (20%)

You must write JUnit 4 test drivers for the Deque interface as well as for your ListDeque and ArrayDeque implementations. All the general test cases should go into DequeTestBase.java whereas test cases specific to ListDeque or ArrayDeque (if any!) should go into ListDequeTest.java and ArrayDequeTest.java respectively.

Be sure to test all methods and all exceptions as well. Note that it is not enough to have just one test case for each method; there are plenty of complex interactions between the methods that need to be covered as well. (And yes, of course you need to test toString! The good news is that these classes don’t have iterators…)

Problem 4: Palindrome Checker (15%)

Your final task for this project is to write a little program called Palin that checks whether input read from stdin is a character palindrome or not. If it was a palindrome, your program prints “Yes”, otherwise it prints “No”, followed any case by a newline.

In order to support “complex” palindromes (more fun!), we’ll ignore characters that are not letters or digits and we’ll disregard case for letters. So while mom and radar are “obviously” palindromes, we’ll also consider classics such as A man, a plan, a canal - Panama! to be palindromes. (With our approach, the above really is amanaplanacanalpanama which, if you check carefully, does indeed spell the same forwards and backwards.)

Your Palin.java program is supposed to use a Deque to check whether we have a palindrome or not: Put the characters into the deque at one end, then once the input has been read keep checking whether the front and the back match repeatedly until you get to an empty deque. (Be careful about the special case close to the end there.)

Hints

General Assignment Hints

Deliverables

You must turn in a gzip-compressed tarball of your project; the filename should be cs226-assignment-number-name.tar.gz with number replaced by the number of this project (see above) and name replaced by the first part of the email address you used to register on Piazza. (For example, Peter would use cs226-assignment-3-phf.tar.gz for his submission of Project 3.) The tarball should contain no derived files whatsoever (i.e. no .class files, no .html files, etc.), but should allow building all derived files. Include a plain text README file (not README.txt or README.docx or whatnot) that briefly explains what your programs do and contains any other notes you want us to check out before grading; your answers to written problems should be in this file as well. Finally, make sure to include your name and email address in every file you turn in (well, in every file for which it makes sense to do so anyway)!

Grading

For reference, here is a short explanation of the grading criteria; some of the criteria don’t apply to all problems, and not all of the criteria are used on all projects.

Packaging refers to the proper organization of the stuff you hand in, following both the guidelines for Deliverables above as well as the general submission instructions for projects.

Style refers to Java programming style, including things like consistent indentation, appropriate identifier names, useful comments, suitable javadoc documentation, etc. Many aspects of this are enforced automatically by Checkstyle when run with the configuration file available on Piazza. Style also includes proper modularization of your code (into interfaces, classes, methods, using public, protected, and private appropriately, etc.). Simple, clean, readable code is what you should be aiming for.

Testing refers to proper unit tests for all of the data structure classes you developed for this project, using the JUnit 4 framework as introduced in lecture. Make sure you test all (implied) axioms that you can think of and all exception conditions that are relevant.

Performance refers to how fast/with how little memory your program can produce the required results compared to other submissions.

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:all we will take off 10% (except if you document a very good reason; no, you cannot use the @SuppressWarnings annotation either). If your programs fail miserably even once, i.e. terminate with an exception of any kind, we will take off 10% (however we’ll also take those 10% off if you’re trying to be “excessively smart” by wrapping your whole program into a universal try-catch).