Question text in black, answers in blue.
isPath to be a boolean
array, do you? Shouldn't it be a boolean?
Yes, you're right. This is now fixed, and you get a point.
isPath or Path. The array
field of Maze should be private -- should I write a public get
method that can get individual cells out of the array?
That would be the way to do it, but I think it is better for the user to specify the source and destination nodes by giving their X and Y coordinates. I have corrected the assignment accordingly, and you get a point.
public class SCell extends Cell {}, and it
wouldn't compile, saying something about "the constructor
Cell( )". What did I do wrong?
I had to look this up in Java Precisely,
but I can now tell you. Since you didn't give a constructor for
SCell, it made the default constructor SCell( ) which calls the
constructor
Cell( ) of its parent. But the latter does not exist, because you
lose
the default zero-parameter constructor when you supply your own.
Before you can make any SCell objects, you will have to write a
constructor for SCell, which will call one of the existing Cell
constructors using super. Then this problem will go
away.
It's much better practice to have a separate method to get each field of an object. In this case you should write a getSeen method (and a setSeen method) as part of the SCell class, to go with the new boolean field "seen".
Even if that would work, you would not be allowed to do it because your spec (my assignment) says that "seen" is a boolean. The extra time and programming effort to change those fields is very small, and clearly you will get wrong answers later if you don't do it.
Yes, you may, but you should only do that if you are confident that your code is correct. (And you won't likely get your Project #1 grade before Project #2 is due.) If you've tested your code thoroughly, you may be confident enough.
Stack<Integer> object and got an error -- what gives?
The generic class Stack<T> is located
in java.util, not the package java.lang that you get
access to automatically. So you should say import java.util.* as
the first line of any class that uses a Stack. The "*" is a wild-card operator
and ensures that you import the whole package, including any classes that Stack
inherits from.
No, because the spec (my assignment) says that it should return an array. It's true that you will have the SCell objects you want in a Stack once you have found a path, but you must create an array and copy the elements into it. (Note that you can easily find the number of elements in the Stack without changing it.)
Stack<Integer> object?
With the constructor. You can see on the Java API, searching for "Stack", that the constructor has no parameters and creates an empty stack.
I tried saying "import jss2.ArrayStack" as L&C do on page 47, but I got an error.
First, you don't need to do that because in this assignment we are using Java Stacks instead of L&C's ArrayStacks. Secondly, your computer couldn't import the package "jss2", which consists of the code that L&C wrote for the book, because it couldn't find it. If we use L&C's code directly later in the class we will make sure that you have access to this code.
Yes. I should have stated this directly, but it follows from the definition. A path should have the source cell first, the destination cell last, and have only open cells, and this is impossible unless both the source and destination are open.
In that case, isn't there a bug in the "moves" method, in that it will give you the open neighbors of a closed cell even though the closed cell can't have paths?
I don't think this is a bug. Of course you can make sure in your path method that the potential source is an open cell, and if the potential destination is a closed cell you will never find a path to it. So we don't need to restrict the moves method that way, and I would argue that we shouldn't. A user later might want to know the open neighbors of a given closed cell (perhaps later it might be possible for closed cells to become open, for example) and we have no good reason to stop them from finding out.
No, I don't want you messing with the signatures of the methods in Maze, except that whenever they returned Cells before they should now return SCells. Really the only changes you should be making in Maze are to change Cell variables, fields, and parameters to SCells. (Of course if you don't think your Maze code was correct, you should fix it, drawing on my code for the solution as needed.)
empty, rather than isEmpty
as you've been writing it. If I use that method for a Stack, I had better use
their name for it, right?
Indeed you should, as the library code will not recognize the other name. Thanks for catching this!
Last modified 25 September 2011