|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Page 4 of 6
Here is how the ordinal numbers are assigned:
public final class Color {
private String id;
public final int ord;
private static int upperBound = 0;
private Color(String anID) {
this.id = anID;
this.ord = upperBound++;
}
public String toString() {return this.id; }
public static int size() { return upperBound; }
public static final Color RED = new Color("Red");
public static final Color GREEN = new Color("Green");
public static final Color BLUE = new Color("Blue");
}
This code uses the new JDK version 1.1 definition of a "blank final" variable -- a variable that is assigned a value once
and once only. This mechanism allows each object to have its own non-static final variable, ord, which will be assigned once during object creation and which will thereafter remain immutable. The static variable upperBound keeps track of the next unused index in the collection. That value becomes the ord attribute when the object is created, after which the upper bound is incremented.
For compatibility with the Vector class, the method size() is defined to return the number of constants that have been defined in this class (which is the same as the upper bound).
A purist might decide that the variable ord should be private, and the method named ord() should return it -- if not, a method named getOrd(). I lean toward accessing the attribute directly, though, for two reasons. The first is that the concept of an ordinal is
unequivocally that of an int. There is little likelihood, if any, that the implementation would ever change. The second reason
is that what you really want is the ability to use the object as though it were an int, as you could in a language like Pascal. For example, you might want to use the attribute color to index an array. But you cannot use a Java object to do that directly. What you would really like to say is:
display(piece[color]); // desirable, but does not work
But you can't do that. The minimum change necessary to get what you want is to access an attribute, instead, like this:
display(piece[color.ord]); // closest to desirable
instead of the lengthy alternative:
display(piece[color.ord()]); // extra parentheses
or the even lengthier:
display(piece[color.getOrd()]); // extra parentheses and text
The Eiffel language uses the same syntax for accessing attributes and invoking methods. That would be the ideal. Given the
necessity of choosing one or the other, however, I've gone with accessing ord as an attribute. With any luck, the identifier ord will become so familiar as a result of repetition that using it will seem as natural as writing int. (As natural as that may be.)
for (Color c=Color.first(); c != null; c=c.next()) {
...
}
or from the end back to the beginning:
for (Color c=Color.last(); c != null; c=c.prev()) {
...
}
These modifications use static variables to keep track of the last object created and link it to the next object: