ITEC120-ibarland (incl. office hrs)—info—lectures—labs—hws

Constructors deconstructed; Boolean expressions

public, private

In lab, we saw code a method public String toString() (for each of class Die, class Player), and we said that public meant that any other object can walk up to a Die and ask it to convert itself toString. If a method or field is declared as private, then other classes cannot use it.
[Demo, making the fields of Die private. What about the random-number generator randy, should we provide getter/setter? Should randy even be mentioned in toString? What about the access privilege for setFace?]

From now on: Make all fields private (always), and all methods public (for now). You only need to provide getters and setters for fields you want other classes to be able to get/set. Within the class itself, you can just refer to the field itself.

Constructors, deconstructed

What exactly¹ happens, when you call a constructor, like new Blarg(…)?

1. Java makes a new Blarg with all of its fields set to a 0ish value (0.0 for float, false for bool, ).
   Note that even if you want some field to have the value 0 initially, you should set it yourself explicitly, so others reading your code know what you really intended, and don't have to guess whether you have a bug of uninitialized variables. (In fact, Java requires this, for constructors. There are other situations (creating arrays) when you don't absolutely need to initialize variables, but it's still something you should do.)
2. Java looks at your class file, from top-to-bottom, and every time it sees a declared (non-static) field which you had initialized, it gives that value to the field.
3. Then, Java runs the constructor code, starting from its first line.

Constructors rarely do anything interesting, besides accept some values which (almost always) are directly put into fields. Note that there are two common naming conventions: You can use parameter names which start with underscores (but otherwise have the meaningful name corresponding to the field):

class Blarg {
  int blargNum;
  String blargName;
  double blargDub = Double.MIN_VALUE:
  bool   blargTF;
  
  /**
   * Construct a Blarg, given
   */
  Blarg( int _blargNum, String _blargName ) {
    blargNum = _blargNum;
    blargName = _blargName;
    blargTF = false;        // This initial value might be provided when 
                            //   the field was declared, as with blargDub.
    }

class Blarg {
  int blargNum;
  String blargName;
  double blargDub = Double.MIN_VALUE:
  bool   blargTF;
  
  /**
   * Construct a Blarg, given
   */
  Blarg( int blargNum, String blargName ) {
    this.blargNum = blargNum;
    this.blargName = blargName;
    this.blargTF = false;       // This initial value might be provided when 
                                //   the field was declared, as with blargDub.
    }

Beware calling methods from constructors

While it's possible to call a method (in the same class) from a constructor, you should be very careful about doing this: People writing the other methods always assume the object being worked with (this) is in a valid, fully-initialized state. But if you call it from the middle of a constructor, you're only half initialized! Even getters and setters should be avoided in this situation. If you have code which needs to be done both in the constructor and in regular methods, then you'll have to be creative². Fortunately, this situation doesn't arise often, as constructors usually just initialize fields more-or-less directly from their parameters.

Exam review

I'll put out a drill-homework as extra credit; it will feature series of questions, all of the form:

• “Declare a variable of type [some-type], initialized to an appropriate value”
• “Consider a function named [such-and-such], with the following signature. Call the function, passing it appropriate arguments, and storing the return result (if any) in a variable.”
• “Here is the javadoc documentation for a method. Write its signature.”
• “Here is an example of calling a particular method. Write its signature.”

Boolean expressions

Read in book, Chapter 5: The type boolean is much simpler than (say) int, because rather than 4+ billion ints, there are only two boolean values: true, and false. Note that these two names aren't variables; they're values, just like 17 and -34 are.

There are some functions in Java which take two numbers, and return a boolean: >, >=, ==, !=, etc..

There is only one built-in Java statement which really uses booleans: that's the if-else statement. Syntax:

if (condition) {
  statements…
  } 
else {
  statements…
  }

/**
 * @param animalType The type of animal (e.g. "newt")
 * @param numInStock The number of the given animal in stock.
 * @return A complete sentence describing the inventory
 * For example:
 * inventoryMessage( "dog", 3 ) = "There are 3 dogs in stock."
 */
String inventoryMessage( String animalType, int numInStock ) {
  return   "There are "
         + numInStock
         + animalType + "s"
         + " in stock.";
  }

  /**
   * @param animalType The type of animal (e.g. "newt")
   * @param numInStock The number of the given animal in stock.
   * @return A complete sentence describing the inventory
   * For example:
   * inventoryMessage( "dog", 3 ) = "There are 3 dogs in stock."
   */
  String inventoryMessage( String animalType, int numInStock ) {
    String answer;
    
    if (numInStock == 1) {
      answer =   "There is "
                + numInStock
                + " "
                + animalType
                + " in stock.";
      }
    else {
      answer =   "There are "
                + numInStock
                + " "
                + animalType + "s"
                + " in stock.";
      }
      
    return answer;
    }

We can do better: Where do the two solutions differ? In only two places: “is” vs. “are”, and the suffix “s” vs. no suffix at all. We can factor out the common code, and let our if statement focus on just those differences:

  /**
   * @param animalType The type of animal (e.g. "newt")
   * @param numInStock The number of the given animal in stock.
   * @return A complete sentence describing the inventory
   * For example:
   * inventoryMessage( "dog", 3 ) = "There are 3 dogs in stock."
   */
  String inventoryMessage( String animalType, int numInStock ) {
    String verbForm;   // The correct verb for our result.
    String plurality;  // The noun-suffix, correctly plural or singular.
    
    if (numInStock == 1) {
      verbForm = "is";
      plurality = "";
      }
    else {
      verbForm = "are";
      plurality = "s";
      }

    return   "There " + verbForm + " "
             + numInStock
             + " "
             + animalType + plurality
             + " in stock.";
    }

Another example:

• Let's rewrite setFace so that if somebody attempts to set the face to too-large of a value, we use the maximum legal value instead.
• Okay, let's rewrite that again, so that we also guard against setting the face to too-small a value.

In your book's reading of Chpt.5, you saw that

1. you can omit the else, if the curly-brackets would be empty:

   /** * @param animalType The type of animal (e.g. "newt") * @param numInStock The number of the given animal in stock. * @return A complete sentence describing the inventory * For example: * inventoryMessage( "dog", 3 ) = "There are 3 dogs in stock." */ String inventoryMessage( String animalType, int numInStock ) { String verbForm = "is"; // The correct verb for our result. String plurality = ""; // The noun-suffix, correctly plural or singular. if (numInStock != 1) { verbForm = "are"; plurality = "s"; } return "There " + verbForm + " " + numInStock + " " + animalType + plurality + " in stock."; }

2. When there is only a single statement in the body, the book reveals that you can conceivably omit the curly-brackets. ³ This is bad for several reasons:
   1. It's fairly common that you decide later to go back and add something to the if- or else- case, and you end up adding the brackets later. Moreover, if you have several lines in a block and delete them down to just one, you'd want to delete the brackets to be consistent (and not cause readers to wonder if there is some unintentional bug).
   2. This usually leads to confusion though, and the book has to spend several minutes talking about dangling elses.
   3. Consider:

      if (numInStock == 1) verbForm = "is"; else verbForm = "are";

      What if we go back, and decide to add the lines for plurality, but we forget to put in curly-braces?:

      if (numInStock == 1) verbForm = "is"; plurality = ""; // DANGER, WILL ROBINSON! else verbForm = "are"; plurality = "s";

      Java gives an error “else without an if” -- why? If we hadn't had any else statement at all, would we have caught our error?

• If the statement is so short it easily fits on the same line as the if or else keyword, you can put it on the same line (without curly-braces);
• When the else-block consists of just a single if, then rather than nest them (even indented as such), it's clearly to have each if/else indented equally, since the branches correspond to equally-important (non-nested) options.

/** Return a greeting, selected randomly from a list of four greetings.
 * @return A greeting (randomly selected, not necessarily uniformly).
 */
public static String greet() {
  int choice = (new java.util.Random()).nextInt(100);
  
  if (choice < 30) {
    return "Hello.";
    }
  else if (choice < 33) {  
    return "Aloha.";
    }
  else if (choice < 50) {  
    return "Buenos dias, amigo/amiga.";
    }
  else if (choice < 99) {  
    return "Yo.";
    }
  else if (choice < 100) {  
    // Not an advisable greeting.  Use sparingly.
    return "System dot out dot println open \"hello\" close.";
    }
  

  String warning = "*** This line of code is unreachable! ***";
  }

• What is the probability of returning Hello? Aloha? Half-open intervals make it easy!
• Is the choice < 100 branch actually ever taken?
• What if we change “< 100” to “<= 100”?
• What if we change “< 99” to “<= 99”?
• As written, it doesn't compile. Why not? Discuss.
• More fundamentally: Should the if (choice < 100) be omitted, so that last return statment is a catch-all? Consider—what if we have some mistake in our series of cases (say, accidentally leaving off the case, for some intermediate range of numbers)? Can the compiler catch such a mistake automatically?
  Guideline: If the final condition is easy to phrase, then certainly include it, rather than use a catch-all branch at the end. But don't bend over backwards, to do this; sometimes formulating that final condition is more error-prone than the savings you'd get!
  Mention: Arguably, it is bad to have more than one return in a method; (rather than always reaching the end of the method and returning a value there, for everybody to easily see). I don't insist on this, but you may have later teachers who do.

connectives

if (statement)
  expression
else
  expression

ITEC120-ibarland (incl. office hrs)—info—lectures—labs—hws

©2006, Ian Barland, Radford University Last modified 2006.Nov.09 (Thu)

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