Home

Wed, 30 Jul 2008 22:22:38 +0200

Welcome to the CS 235 Anti-Gotcha Page

A word of help for all labs from the TAs:

NEVER change the interfaces provided on the class webpage. It might run fine and compile on your machine, but it will not compile when you upload it to the passoff driver. Just a heads up so you don't have to do a lot of fixing after you thought that you had finished the lab.

Lab 1

equals method
When you implement the "equals" method in your "Person" class, you might be tempted to do something like this:

public bool equals(Person other) {
...
}

This will compile and run without any errors or indication that you have made a mistake, but you have not correctly overloaded the default implementation of equals. The default implementation will still be called, not yours. You must follow the interface definition precisely:

public bool equals(Object other) {
Person otherPerson = (Person)other;
...
}

--------------------------------------------
null wholey null, and nothing but null
The TestDriver will pass empty strings into your objects and expect them to pass as valid new objects so don't do any empty string checking - only check for null references.

----------------------------------------------

Working with the PersonIO

I decided to iterate through the array and learned about how to check if my variable was a student or a person etc...

for (Person i:tempArr)
{
//check if person is a student
if(i instanceof Student)
{
StudentImpl tempStu;
tempStu = (StudentImpl) i;
tempStu.getMajor();

I then used the tempStu object to run the calls I needed to build the information to export to the text file. Thought it might help... Good luck!

-Ross

A note on the above technique:

Although it works, it is perhaps not ideal in terms of design or speed. We are dealing with related classes; the point of having them inherit from a common parent is so that you can treat them the same. Remember that each child of Person already defines its specific version of toString() implementation that will take care of the differences for you, without having to expend lines of code and processing power determining the class of each object. Let object-oriented programming do the work for ya!

-Jordan

Yeah I slapped myself on the head, should have fixed the above "example" after I fixed my code eh?

tempStr += i.toString(); //Rules!

-Ross

------------------------

Lab 2

A note on Print debugging:

if you want to type less by making a method in your class to print, there are two things that can help you print what you want.

If your method is:

private static void myPrint (String output){

System.out.println (output);

}

then to print objects you need to concatenate a string (even empty ones: "" ) to automatically call the toString method of that object. eg: myPrint ("MyObject is" + MyObject) automatically calls MyObject's toString

The other way to print objects other than strings is to make your method accept Objects instead:

private static void myPrint (Object output){

System.out.println (output.toString()); // call te toString of whatever you passed

}

then you can pass objects, integers, etc, without concatenating a string to them first.
------------------------

Lab 3

Working With Recursive Algorithms

Like Bro. Gashler, I tend to be a text editor + terminal window kind of guy (btw, TextMate for OS X and its Windows equivalent, the "E Text Editor," are awesome). However, in certain situations, it can really help to have a debugger available that allows you to step through code as it is being executed, line by line, and the ability to track certain variables and see how they change. In my opinion, recursive algorithms like the sort used in Lab 3 are perfect examples of this.

To start, grabbing a pen and paper and working out how an algorithm should work ended up really helping me in this project. I stepped through the process of spelling words from a board in my head, and this helped me realize what the algorithm needed to include.

Once you have some code, using an IDE like NetBeans ( http://www.netbeans.org/ ) that includes the ability to "debug" code as it executes can help you to see what happens as your algorithm does its thing. Pay special attention to "special events" like:

A prefix is not found in the dictionary

A word is finally located

A new starting point must be used

Personally, recursion can make my head hurt. Usually I can code by just letting my brain and the keyboard work together, but tools like debuggers are great when complexity increases. Use them!
-Jordan

Using checkstyle even though you don't have to

Eclipse has an easy-to install plugin for checkstyle http://eclipse-cs.sourceforge.net/
~Anonymous person that may or may not use an IDE

Just another thought

Make sure that you check for duplicate words in your getAllValidWords method.

~James

Lab 4

When implementing the write function on your document class, dont worry about adding white space, all the necessary white space is already stored in text nodes throughout your tree, just iterate through it and print each nodes contents.
----------------------

Lab 5

Anyone else having trouble with the remove() method? I've been working on this lab for about 24 total hours (not consecutive!) now. Any help is appreciated. I keep getting stack overflows from my removeMin that my node classes use to tear off and return the first sorted item, as soon as that node is referenced again. Something's pointing to itself? maybe? Feel free to delete this message when something helpful has been written. It is 11:04 P.M., Mon July 28. Another late night with little progress. Can't blame the TAs for not wanting to stay up all night, too.

Lab 6

The TestDriver provided requires that your BinaryTreeNode interface has the method getData (), but the PassOffDriver requries that the method be called getObject(). Just put BOTH methods in the BinaryTreeNodeInterface AND in your implementation. (I know your not 'supposed' to change the interface, but you got to do what you got to do).

Enzym RSS