RU beehive logo ITEC dept promo banner
ITEC 120
2008spring
ibarland,
jdymacek

homeinfoarchiveexamslectureslabshws
RecipeLawsliessyntaxjava.lang docsjava.util docs

lect10a-soln
static fields

Reminder: static methods

(You can check your answers.)
warning (again): The Java keyword “static” means “associated with the class, not a particular instance”. It does not mean “unchanging”.

static fields

The concept of “belonging to the class-blueprint, not any particular instance” can also applies to fields, as well as methods. Most of the time, static fields are used for named-constants, so we'll discuss that first, followed by an example of a static field which isn't constant.

Named constants revisited1

Named constants in other classes:
Math.PI,
Integer.MAX_VALUE,
Double.POSITIVE_INFINITY,
Double.NaN.

We can make our own named constants. As before, “static” is an adjective that we write in front of the variable-declaration.

  public static double MINIMUM_WAGE = 5.15;
  public static double PRICE_PER_SQ_IN = 3.14;
Other people then use these by writing the “classname-dot” (not “object-dot”): if (newSalary < PizzaServer.MINIMUM_WAGE) ....

Non-constant static fields: PizzaServers strike together

Suppose occasionally, all PizzaServers might go on strike together. This means that their salary becomes zero until the strike is resolved.
Hint: Don't try to go and change the salary field of every single PizzaServer that has ever been created. (We don't even know how we could do that yet.) Instead, always keep the same salary field inside a PizzaServer, but when that PizzaServer is asked its salary, it first checks whether it's currently on strike and in that situation answers 0 instead of the value stored in the field.

class PizzaServer {
  private static boolean onStrike = false;

  /** Flip ("toggle") the status of whether or not we're on strike.
   *  (This method plays the role of a setter, in a way.)
   */
  private static void toggleOnStrike() {
    // ...?
    }

  /** Return whether or not all PizzaServers are currently on strike.
   * @return whether or not all PizzaServers are currently on strike.
   */
  private _______  _______ getOnStrike {
     // ...?
     }

  /** Return the amount to pay this PizzaServer.  If on strike,
   *   this will be zero.
   * @return the amount to pay this PizzaServer, in $/hr.
   */
  double getSalary() {
    // ...?
    }
}

Non-constant static fields: idNum

Another common use of static fields is to keep track of how many times (say) the constructor has been called. This can be useful for making objects which have an ID field

class PizzaServer {
  private static int createdSoFar = 0;

  private int id;
  // ... other fields omitted

  // constructor
  public Treasure( /* ... */ ) {
    this.id = createdSoFar;
    PizzaServer.createdSoFar = PizzaServer.createdSoFar + 1;
    // (Or, if we had declared a (static) getter/setter:
    //    PizzaServer.setCreatedSoFar( PizzaServer.getCreatedSoFar()+1 );
    // This is the similar to what we back in PizzaServer's "addToBalance",
    // except that this time it's a static field we're changing, that's all.
    }

  }
Draw a picture of what is happening, when making several PizzaServers.

Style: People usually don't write getters/setters for static fields. There's no reason you couldn't do that, though. (Should a setter/getter for a static field itself be a static method?      yes      Does it absolutely have to be?       no       What are the drawbacks, if it's not?   You couldn't get/set the field without having created some object of the class. In fact, you might even drive other programmers to create a new Treasure object solely for the purpose of getting the static field -- what a waste!  )

Also, note that in the code above, if you leave off the class-name Treasure., java would write it in for you. This only works when referring to a static field/method within the same class you're writing, of course; Player objects would need to refer to Treasure.createdSoFar to refer to that field in the other class. And of course, it would fail since createdSoFar is private, within class Treasure.

If there is left-over time in lecture, we'll talk about test drivers.


1 We aren't quite yet finished with how Java lets us best express named-constants; we'll see one more keyword before we're done. We started by using local-variables (because that's all we knew), improved that to fields (so that different methods could refer to the same constant), and now make it static (since named constants aren't part of a object's individual state).      

homeinfoarchiveexamslectureslabshws
RecipeLawsliessyntaxjava.lang docsjava.util docs


©2008, Ian Barland, Radford University
Last modified 2008.Mar.24 (Mon)
Please mail any suggestions
(incl. typos, broken links)
to iba�rlandrad�ford.edu
Powered by PLT Scheme