ITEC120

lab06:
get, set, ... construct!

Today we'll work in pairs, trying BlueJ features we've seen in class, and adding our own constructors. There will be little snags to work around and changes you'll need to make to the code; discuss with your partner, what/how/why certain changes work (or, don't work).

• Take the Die example we've been developing in lecture.
  • Use BlueJ to create a six-sided die, and a hundred-sided die. Select each object on the bench, and right-click and Inspect the objects; leave those inspection-windows on the screen.
  • Roll each die.
  • By typing into BlueJ's codepane, declare a variable named dodec of type Die, and initialize dodec to be a 12-sided¹ die.
  • Roll dodec a few times (by typing into the codepane, not via any pop-up menus).
  • You've now used Dice (learning their interface); let's now consider their implementation.
    With your partner, look at the code for the constructor, and discuss whether you understand what Java is doing. How is a constructor's signature different from all other methods? The constructor's name is always exactly the same as ________________.

  • We retreated in class a bit, and had set the initial value of the field face to be 1, because we don't know the largest size until somebody actually creates a new Die. This made marketing sad, and sales plummeted since nobody bought dice which said 1 straight out of the factory.

    Change the constructor so that we really do set the face of the die to be the maximum value. Change the place where the field face is first declared, and don't give it any initial value there.

    Test that you can still create and roll a Die.

  • Add the following method:

    /** Look at the bottom of the die, without changing the Die's state. * @return the number on the *bottom* face of the Die. */ int getOppositeFace() { ... }

    In order to write this, you need to know something about how dice are made:
    • For six-sided dice, the opposite faces always add up to seven. So if a five is showing, I know right away that a two is on the bottom face. Similarly, if a three is showing, what is on the bottom face? (How did you calculate that?)
    • If a die has than twelve sides, then opposite faces add up to ...thirteen! In general², if a die has N sides, then its opposite faces will add up to N+1.

---

Much of class Die was putting together knowledge we had already learned, but writing the constructor (which took arguments) was new, as well as having a field NUM_SIDES which wasn't initialized right when it was declared. Let's write a small new class with this same idea.

• The manager of Carry's Cadillac Company has determined that when people are considering whether to buy a particular Cadillac, there are really only a few things that they ever ask about: The car's price, its miles-per-gallon (as determined by government tests), its Vehicle ID Number (the “VIN”), and the state tax rate on buying cars.

  Carry hires you to make a Java class representing this information about the Cadillacs in her lot. You start wondering what data (fields) you need to keep, and whether each of the fields are static, and whether they are final. You go back and get some clarifications from her:

  • Each car has its own price. The price is always a whole number of dollars. Initially³, she prices each car at $23,500, but a particular car's price might change over time, depending on whether she marks it down to sell quickly. (She never keeps around old-model cars!)
  • Each car has its own VIN, which is a bunch of characters-and-digits, like “4YTV7 2AB22”. A car's VIN will never change. When a car rolls on to Carry's lot, and she first creates a Java object corresponding to it, she will look up the VIN and pass it in to the code.
  • The miles-per-gallon which Cadillacs get is the same for all cars on her lot. This mileage-rating might change from year to year though, when she gets a whole new batch of cars. (The mileage-rating always a single whole number, like 18.)
  • The state tax when buying any car is 3%. It is fixed by the legislature, and never changes. (If it does change, she's willing to re-start her program.)

  Your task: Start to write class Cadillac. Include fields for the above information, deciding whether each field is final, static, and can be initialized when you declare the field, or whether you can't initialize it until the Constructor is called.
  Then, write the constructor.
  (You'll need to decide, which information the constructor needs to be given when each car is made!)

  You don't need to write any methods, but should be able to construct Cadillacs instances (and inspect them in BlueJ).
  To think about: which fields will have getters? Which will have setters?

For Sep.29 (Fri)

With a partner, finish the above tasks, and the one next method, and we'll check them off.

solution

toString, and more behind-the-scenes Java

Recall how the code "Catch-" + 23, which looks like it's trying to concatenate two things which aren't both Strings, actually gives a String result: Java, behind the scenes, converts the int 23 into a String⁴ (at which point doint string-concatenation is no problem).

This help from Java is convenient, when we want to convert ints and doubles into Strings. But Java generalizes this philosophy of “convert-numbers-into-strings-as-needed” a bit further, to all values, not merely numbers! Try typing this in BlueJ's codepane:

Cadillac myRide = new Cadillac( whatever-arguments-needed-for-constructor );
"I bought " + myRide + " at Carry's Caddy Co."

Here is what was happening: Java converted "I bought " + myRide + " at Carry's Cadicallac Co." into "I bought " + myRide.toString() + " at Carry's Cadicallac Co.". And, Java (again working behind the scenes) wrote its own version of toString for Cadillacs for us.

But if we can do a better job, we can write our own method toString for Cadillacs, “overriding”⁶ Java's default version toString:

/** toString: Return a String representation for this Cadillac.
 * @return A string, showing the state of this Cadillac (non-static fields only).
 */
public String toString() {
  return …
  }

Then, try the following:

Cadillac myRide = new Cadillac( whatever-arguments-needed-for-constructor );

"I bought " + myRide.toString() + " at Carry's Caddy Co."
"I bought " + myRide            + " at Carry's Caddy Co."

Since Java lets us override toString for any class, we'll often take advantage of this, and require it for most future assignments. Note that in software companies, it's often required to have all classes override toString; this policy is helpful when inspecting objects which were passed to you from other parts of a project:

If you have some object, just call its method toString, to get a String describing that object.

public?

Note that We're having you add one new, mysterious word: “public”. We'll discuss this keyword in lecture on Monday, but as a quick preview: it means that other classes (besides class Cadillac) are allowed to call this method. For example a PizzaServer would be able to walk up to a Cadillac and call its toString method, but the PizzaServer might not be allowed to call a car's setPrice method: that method might be “private”, and perhaps only Carry will be allowed to set a car's price.

Java's policy that “anybody can call an object's toString method” entails that toString always be public. Java will complain if you define this method but try to make it private (or, if you leave off the public keyword at all).

©2006, Ian Barland, Radford University Last modified 2006.Sep.29 (Fri)

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