ITEC120-ibarland—info—lectures—labs

finishing Booleans; syntax review

Reviewing hw03

(2006.Oct.09, Mon) Some key elements from the hw03 solution:

• The testDog method inside class Dog is an alternative approach to testing, instead of doing lots of clicking on BlueJ windows and calling methods. That clicking-approach to testing becomes more cumbersome as (a) the return-values depend on an object's state as well as the input, or (b) there are methods with no return value (like setters), and (c) changing one method may or may not influence other methods which suddenly need re-testing.
• The class Kennel contains three Dogs. (Says so, right on the assignment.) That means three fields, each of type Dog, with no other fields. A Kennel does not contain names or ages, only Dogs. (Each Dog will keep track of its own name and age.)
• The job of the Kennel constructor is to make sure that all fields get initialized. The first Dog is easy to initialize; heck we know what it is going to be be even before anybody even calls new Kennel. But the other two dogs... like class Die, we don't know all the info we need until the moment somebody calls new Kennel and passes in some names.
  At that point, what should the kennel set their dog1 field to? How about their dog2 field?
• Getters and setters are always easy. What type does getDog2 return? A Dog. (Not a String, nor an int.) What type should setDog2 take in, as an input? A Dog. (Not a String, nor an int.)
• If you have created a kennel k, how do you find out the name of its dog2? You can't call k.getDog2Name, because a Kennel only has getters and setters for its fields, and its only fields are Dogs (no names or ages).
  The only remotely helpful Kennel behavior is getDog2. That returns a Dog. Aha, once we have a Dog, we know we can ask the dog what its name is! So:

  (k.getDog2()).getName();

  or equivalently

  Dog myTempDogVariable = k.getDog2(); myTempDogVariable.getName();

ITEC120-ibarland—info—lectures—labs

Comparing doubles

double x = 2.0 - 1.1;
double y = 0.9;

x == y
// huh?  That's an unexpected answer.  How to debug?

x
// Oh, now it's clear what happened.

Returning boolean

Passing in booleans

Back in an early lab, we wrote a couple of methods salesTaxOn and priceAfterTax. But some items are tax-free. Change priceAfterTax so that it accepts a second argument isTaxable — a “flag” indicating whether or not this item is subject to sales tax.

Naming convention: start boolean variable names with “is”.

Overloading

Interestingly, we can have two versions of priceAfterTax in the same class. Even though they have the same name, when somebody calls one of them, it's possible to distinguish which one of the two functions they want: by looking at the full signature (do they pass a double, or a double-and-a-boolean), Java can tell which method was intended.

Repeated code? How to avoid this? Have one of the two functions call the other, filling in the “default” arguments! This is a very common pattern: one primary version of the function taking many arguments, and several smaller versions with fewer arguments, each method just adding one default argument and calling the next version. Alternately, often there are exactly two versions of a function: one version taking the common arguments, plus one big version with all sorts of rare arguments²

Consider an example from an early lab: the sales tax on most items is 5%, but on cars it is 3%, and houses have yet a different rate. Now we can have three methods: taking a price, taking a price and a flag “isTaxable”, taking a price and a flag and a tax-rate. Write this. (You could also conceive of taking a price and a tax-rate without a flag “isTaxable”, but we won't do that here.

Notes on overloading: You must be able to distinguish them just by the input types; Java doesn't use the return type (partly because it does so much auto-converting of things to Strings behind-the-scene).

Overloading is convenient, but not a deep concept: if the language didn't provide it for us, we'd just give slightly different names to each function (“salesTax_isTaxable”, “salesTax_isTaxable_taxrate”, etc.). After all, when somebody is calling the function, they know right then exactly which flavor of the method they want, so they'd know which name to call. Having the language allow overloading just lets us avoid having to think up and remember several similar names.

ITEC120-ibarland—info—lectures—labs

Review

We've covered a lot of Java syntax over the last seven weeks. Here's a not-quite-complete list of what we've covered:

• class-declaration ::=
  class name_Class {
     field-declarations…
     constructor-declarations…
     method-declarations…
  }
• field-declaration ::= (public | private) [static] [final] type name [= expression];
• type ::= primitive-type | [name_package.]name_Class
• primitive-type ::= int | double | boolean | char
• constructor-declaration ::=
  (public | private) name_Class ( parameter-declarations… ) {
    statements…
  }
• method-declaration ::=
  (public | private) [static] type_return name ( parameter-declarations… ) {
    statements…
  }
• statement ::= assign-statement | return-statement | method-call_void | if-statement | if-else-statement | local-variable-declaration
• assign-statement ::= name = expression;
• return-statement ::= return expression;
• local-variable-declaration³ ::= [final] type name [= expression];
• expression ::=
  literal-value | name_field | name_local-var
  | expression+expression | expression-expression | expression*expression | expression/expression
  | ( expression )
  | method-call_nonvoid | static-method-call | constructor-call
• method-call ::= instance-expression .( argument-list )
• static-method-call ::= Class-name .( argument-list )
• argument-list ::= empty-argument-list | non-empty-argument-list
• empty-argument-list ::=
• non-empty-argument-list ::= expression [, non-empty-argument-list]

The book's Appendix L has a complete description of Java's syntax. It gives it in a more visual format (its circular boxes correspond to our code font, its square boxes correspond to our nonterminal font, its loops correspond to our “…” (“0 or more”), its splitting-paths options correspond roughly to our | “or”, and its path-which-optionally-bypasses-a-section corresponds to our [bracketed-optional-parts].

ITEC120-ibarland—info—lectures—labs

©2006, Ian Barland, Radford University Last modified 2006.Oct.12 (Thu)

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