In Java, classes and their methods (along with other things) can have different levels of visibility. We have not discussed this in the text yet. Here are the possibilities and some explanation.
If you don't mention any visibility then a class or method can be seen within the package in which it is defined, except that methods have no more visibility than their classes.
If you tag a class or method with public then it can be seen everywhere including other packages. (Again except that a method has no more visibility than its class.
The Harvester class we finished with in Section 3.9 might better be defined by:
public class Field_Harvester extends Harvester
{
public void harvestField()
{ move();
harvestTwoRows();
positionForNextHarvest();
harvestTwoRows();
positionForNextHarvest();
harvestTwoRows();
move();
}
}
If you tag a class or method private then it can be seen and used only within that class. Since the moveToNextRow method of Harvester is intended to be used only within the class, it would be good to make it private.
private void goToNextRow()
{ // Before executing this, the robot should be facing East,
// on the last corner of the current row.
turnLeft();
move();
turnLeft();
}
This is actually a guard against errors. If this method is called when it should not be, from code outside the class, then a Harvester might not do the right thing. This is especially important since this method has a precondition that must be true before it is executed. If it can be executed only from within this class then the author of the class can assure that the precondition is met each time it is called. Another programmer, writing a different class, might not be expected to be quite as careful. This guards against the possibility.
Since it is possible to write a class in one package, but extend it in another in Java, the language provides a mechanism to aid in this. While it is seldom used, if you mark a class or method protected you can see and us it both in the package in which it is defined and in subclasses of the class defined outside the package. We won't make use of this in this book.
Note that a careful reader might wonder what use things like private classes could possibly be. We shall see in Chapter 4 that they have their place since we can actually put classes inside other classes.
If you use successive refinement to develop a robot's actions, the methods you discover in the first part of your analysis, the general breakdown of the task, will need to be public. The others will generally be private. However, some of the auxiliary methods might be made public on occasion, though this is rare. In fact, the Harvester class has a flaw in that we have a public class with a precondition. The Field_Harvester class makes up for this in some ways, since it guarantees that the methods it inherits from Harvester are executed in the right sequence. While we don't completely avoid the need for preconditions here, we lessen them with this technique. We will learn more about how preconditions can be avoided in future chapters, by letting the robot itself establish them.