ITEC120

intro to Objects, continuted

Review from lecture:

For fields, provide getter and setter methods. Your own code should use the getter and setter methods, rather than access the field (code like PizzaServer's balance) directly. (With the exception, of course, of the getter and setter themselves.)

• Suppose Amy in Accounting decrees that every time the balance field is set, an entry must be made in a log file.
• Suppose that our idea of the balance becomes more sophisticated than a single number -- perhaps there are really a principle, some interest, and additional “unavailable funds” (checks which haven't cleared). We might get rid of the field balance and replace it with three fields, but the method getBalance still makes sense; it returns the sum of all three of these.

Last time, we started to write class Die, detailing what behaviors and state it has. We got something like:

 1  /**
 2   * A class representing a die (the thing you roll to get a number;
 3   *   nothing to do with kicking the bucket.)
 4   * @author Ian Barland
 5   * @version 2006.Sep.22
 6   */
 7  class Die {
 8  
 9    /** The number of sides on the die. */
10    final static int NUM_SIDES = 6;
11  
12    /** The currently-showing face/side: a number in 1..{@value NUM_SIDES}. */
13    int face = MAX_SIDES;
14  
15    /** Set the die's face.  (Hey, this is kinda cheating!)
16     * @param newFace the new number to set the die's face to.
17     */
18    void setFace(int newFace) {
19      ...;
20      }
21  
22    /** Return the currently-showing face on the die.
23     * @return the currently-showing face on the die.
24     */
25    int getFace() {
26      return face;
27      }
28  
29    
30    
31    /** Roll the die, and return the newly-showing face-up number:
32     * @return the resulting face (in 1..{@value NUM_SIDES}).
33     */
34    int roll() {
35      ...;
36      return ...;
37      }
38  
39  
40    }

Continue: How to implement setFace? That's pretty easy.

In BlueJ: demonstrate inspect, from an instance's pop-up menu. Call setFace and getFace. What happens if I call setFace(23)? Ah, clearly, in the future, setFace might have some safety code inside of it, to make sure it's set to a legal value. This is another reason for using a setter method setFace rather than just setting the field directly: we can put that safety code (a “sanity check”) in a single place, and we'll catch bugs earler (rather than assigning a bogus value to the field directly, and not catching the error until too late, if at all).

Continuing with implementing class Die: How to implement roll?

/** Roll the die, and return the newly-showing face-up number:                
 * @return the resulting face (in 1..{@value NUM_SIDES}).                     
 */
int roll() {
  java.util.Random randyGen = new java.util.Random();
  int newFace = randyGen.nextInt(6) + 1;
  setFace( newFace );
  return newFace;
  }

1. not setting the face, just returning the value;
2. trying to return randyGen rather than the number randyGen chose for us.)

Is this code ready to be graded? I mean, it compiles, and it runs, and we've used test-cases, and verified that it runs correctly. ...but, does it obey the Laws of Programming? Let's see...

• Human readable? ...Good documentation (good variable names) and indentation, yep.
• Writing test cases, before writing the code?
  Hmmm, we'll come back to this one. A superficial problem is that test cases are difficult since the answer isn't well-defined. More intrinsically, there is the problem that running test cases involves several calls to the method (to verify that the state changes), as well as calls to getFace too. Hopefully we'll talk about test-suites soon (“unit testing”).
• Repeated code? …Nope, not much code, so nothing repeated here or elsewhere.
• Magic numbers? Yikes! A 6, and a 1. Well, the +1 isn't really a magic number; 0 and 1 and -1 (and occasionally 2) don't need special names. But how to get rid of that magic number 6? Ah wait, we already have a final static field NUM_SIDES (included in a moment of foresight). We just need to use it.

Okay, so now we're ready to grade this program? Yes and no. I want to talk about how Die behaves when being rolled many times. In particular, how many java.util.Random instances do we create, using new? ...[continue that discussion, and fix]...

Write a class MonopolyPlayer. Ask the same questions as before. We'll only implement one behavior though: rollDicePair.

MonopolyPlayer Solution

Review: We've seen two keywords, that mean different things for fields:

• final: this value will never change, as long as this field/variable is around.
• static: this field is associated with the entire class, instead of each instance of the class having its own copy.

• int wealth = ...; A regular field; each player has their own copy of this field, and it can change over time.
  
• static int numPlayers = ...;
  The value of this field can vary (decreasing one by one as players go bankrupt), but all Player instances share the same variable.
• final String playerName;
  Such fields vary from player to player, but they never change throughout the game. They are declared up with other fields, but assigned its value in the constructor.
• final static int MAX_PLAYERS = 6;
  (part of the rules of Monopoly).
  These fields are the (only) ones written in all-caps; they are declared and initialized up near the top of the class.

That above is all about fields. What about local variables, inside methods?
Using final still has its meaning; so far, we have only seen and used final variables (used to give a name to some partial-result, esp. if that partial-result will be used repeatedly to return your function's final answer).

Using static, though, does not make sense inside a method: variables declared local to a method aren't in the scope of other instances of that class¹

©2006, Ian Barland, Radford University Last modified 2006.Oct.04 (Wed)

Please mail any suggestions (incl. typos, broken links) to ibarlandradford.edu