Reading data from files and other classes

After all this time, I still don't understand how to read method from other classes and file. I know about the accessing the file, but...

I have three classes...Robot, RobotDriver, and Coordinates, and a txt file. The txt file has commands followed by x, y coordinates.

We were given a formula: distance = sqrt(x*x + y*y) to determine distance between the current position and the origin. I understand on paper how everything is supposed to work. I just don't understand how you add new coordinates x, y to the current coordinates x, y. And that is only the first of my questions.

It starts out at (0.0, 0.0). When the command goRelative 17.2 14.6 is given the new position is (17.2, 14.6). If the command goBack is given, the robot should return to the previous coordinates, in this case (0.0, 0.0). If, instead of goBack, the command goRelative 5.1 -3.2 was given, the robot would end up at (22.3, 11.4)

jiju ka
Ranch Hand

Joined: Oct 12, 2004
Posts: 306

posted Dec 07, 2005 17:09:00

0

I just don't understand how you add new coordinates x, y to the current coordinates x, y.

It is more clear now. You want to do something like

You may create an instance of Robot

Depending on how many goBack's you can do in succession, you may choose to keep history on the currentPosition of Robot. This history may be kept inside Robot class.

For example each time you call goRelative(relative cordinate is supplied) the current co-ordinates could be pushed to stack while creating a new cordinate by adding current cordinate to relative cordinate. The algorithm for GoRelative will look like

Originally posted by Stephanie Dears: This assignment is called a robot in a minefield.

It starts out at (0.0, 0.0). When the command goRelative 17.2 14.6 is given the new position is (17.2, 14.6). If the command goBack is given, the robot should return to the previous coordinates, in this case (0.0, 0.0). If, instead of goBack, the command goRelative 5.1 -3.2 was given, the robot would end up at (22.3, 11.4)

This is a perfect opportunity to learn how to test-drive your programming. Have you ever used JUnit? If you're using an IDE like Eclipse, it's fairly easy to get started with JUnit.

If you're interested, we can help you through the steps you'd take to test-drive the development of this program. You'd start by writing a unit test first. Here's a possible snippet:

The unit test basically outlines what you want the results to be. Another example: to test your Coordinate class, you might write the following test:

Next, you'll run the JUnit test you wrote and see that it fails. It fails because you don't have any code that works. So you go and write code that makes the JUnit test pass. When a test passes, you know that you've made a step closer to having a working program. You continue with this test-code-test process until you have a fully working program. I've left a few things out but that's basically the idea.

At first glance, you may think that it's an advanced technique and that only experienced programmers should attempt it but there are a lot of people, including myself, who think it's a good way to learn how to program and think in terms of objects. Tell me if you're interested and I'll try to help you through.

Stephanie Dears
Ranch Hand

Joined: May 26, 2005
Posts: 43

posted Dec 08, 2005 09:02:00

0

But the coordinates are in a text file. So instead of robot.goRelative(2.5, 2.5) how do I tell it to read the next line from the file?

Break your problem down. The fact that commands are in a text file is an implementation detail. Try to think a little bit more abstractly: Commands come from some kind of Source. That's all that other objects should care about. Here's a test I'd write:

The test also illustrates how you would use a CommandSource to encapsulate the fact that commands come from a text file. Other objects are really only concerned with calling the nextCommand(). For example, I can see creating a Robot like so:

You can write the Robot class so that it doesn't care commands are actually read from a text file. All it cares is that it has a reference to a CommandSource object and that object can provide a series of commands via its nextCommand() method. Notice that a lot of the program code could/would come from the tests you would write for the different classes.

You may want to start with just reading from the file and printing each line, then figure out what else to do with each line. Here's an example of reading text from a file. There's also the Java Tutorial on IO and specifically File Streams, but I have mixed feelings about that one. Do you have an intro Java book of some sort? Does it have a section on FileReader and BufferedReader? [ December 08, 2005: Message edited by: Jim Yingst ]

Stephanie, I'm afraid I've just overwhelmed you with a lot of things that are probably very foreign/new to you so let me back up a bit.

So, you have the classes Robot, RobotDriver and Coordinate, right? Try to think of the responsibilities of each class and how they would be used by other classes:

Robot: can be told to goRelative(), goBack()

RobotDriver: what does this class do? From the name, I can make a guess that it should tell a Robot what to do. If this is true, it should be responsible for reading in commands (perhaps from a text file).

But the coordinates are in a text file. So instead of robot.goRelative(2.5, 2.5) how do I tell it to read the next line from the file?

I am assuming the text file contains the commands. For maintenance sake it will be better to isolate the command-triggering from Robot. Let's say an "operator" is reading the commands from a text file and dispatches the command to Robot. Does it make sense?

You can have a class called Operator which have a method called getCommands. The getCommands method reads the text line by line and stores the command in a Command List. "CommandList" could be a variable inside operator.

After the getcommands, create an instance of Robot with initial position at origin. Then iterate through the command list and issue each command one by one to the Robot.