(or How Objects Can Change Your Life)

Once upon a time in a software shop, two programmers were given the same spec and told to “build it”. The Really Annoying Project Manager forced the two coders to compete, by promising that whoever delivers first gets a cool Aeron™ chair and adjustable height standing desk like all the Silicon Valley guys have. Larry, the procedural programmer, and Brad, the OO guy, both knew this would be a piece of cake.

Larry, sitting in his cube, thought to himself, “What are the things this program has to do? What procedures do we need?”. And he answered himself , “rotate and playSound.” So off he went to build the procedures. After all, what is a program if not a pile of procedures?

Brad, meanwhile, kicked back at the cafe and thought to himself, “What are the things in this program... who are the key players?” He first thought of The Shapes. Of course, there were other objects he thought of like the User, the Sound, and the Clicking event. But he already had a library of code for those pieces, so he focused on building Shapes. Read on to see how Brad and Larry built their programs, and for the answer to your burning question, “So, who got the Aeron and the desk?”

In Larry’s cube

As he had done a gazillion times before, Larry set about writing his Important Procedures. He wrote rotate and playSound in no time.

rotate(shapeNum) {
   // make the shape rotate 360º
}
playSound(shapeNum) {
   // use shapeNum to lookup which
   // AIF sound to play, and play it
}

At Brad’s laptop at the cafe

Brad wrote a class for each of the three shapes

Larry thought he’d nailed it. He could almost feel the rolled steel of the Aeron beneath his...

But wait! There’s been a spec change.

“OK, technically you were first, Larry,” said the Manager, “but we have to add just one tiny thing to the program. It’ll be no problem for crack programmers like you two.”

“If I had a dime for every time I’ve heard that one”, thought Larry, knowing that spec-change-no-problem was a fantasy. “And yet Brad looks strangely serene. What’s up with that?” Still, Larry held tight to his core belief that the OO way, while cute, was just slow. And that if you wanted to change his mind, you’d have to pry it from his cold, dead, carpal-tunnelled hands.

Back in Larry’s cube

The rotate procedure would still work; the code used a lookup table to match a shapeNum to an actual shape graphic. But playSound would have to change.

playSound(shapeNum) {
   // if the shape is not an amoeba,
      // use shapeNum to lookup which
      // AIF sound to play, and play it
   // else
      // play amoeba .mp3 sound
   }

It turned out not to be such a big deal, but it still made him queasy to touch previously-tested code. Of all people, he should know that no matter what the project manager says, the spec always changes.

At Brad’s laptop at the beach

Brad smiled, sipped his margarita, and wrote one new class. Sometimes the thing he loved most about OO was that he didn’t have to touch code he’d already tested and delivered. “Flexibility, extensibility,...” he mused, reflecting on the benefits of OO.

Larry snuck in just moments ahead of Brad.

(Hah! So much for that foofy OO nonsense). But the smirk on Larry’s face melted when the Really Annoying Project Manager said (with that tone of disappointment), “Oh, no, that’s not how the amoeba is supposed to rotate...”

Turns out, both programmers had written their rotate code like this:

1. determine the rectangle that surrounds the shape

2. calculate the center of that rectangle, and rotate the shape around that point.

But the amoeba shape was supposed to rotate around a point on one end, like a clock hand.

“I’m toast.” thought Larry, visualizing charred Wonderbread™. “Although, hmmmm. I could just add another if/else to the rotate procedure, and then just hard-code the rotation point code for the amoeba. That probably won’t break anything.” But the little voice at the back of his head said, “Big Mistake. Do you honestly think the spec won’t change again?”

Back in Larry’s cube

He figured he better add rotation point arguments to the rotate procedure. A lot of code was affected. Testing, recompiling, the whole nine yards all over again. Things that used to work, didn’t.

rotate(shapeNum, xPt, yPt) {
// if the shape is not an amoeba,
   // calculate the center point
   // based on a rectangle,
   // then rotate
// else
   // use the xPt and yPt as
   // the rotation point offset
   // and then rotate
}

At Brad’s laptop on his lawn chair at the Telluride Bluegrass Festival

Without missing a beat, Brad modified the rotate method, but only in the Amoeba class. He never touched the tested, working, compiled code for the other parts of the program. To give the Amoeba a rotation point, he added an attribute that all Amoebas would have. He modified, tested, and delivered (wirelessly) the revised program during a single Bela Fleck set.

So, Brad the OO guy got the chair and desk, right?

Not so fast. Larry found a flaw in Brad’s approach. And, since he was sure that if he got the chair and desk, he’d also get Lucy in accounting, he had to turn this thing around.

LARRY: You’ve got duplicated code! The rotate procedure is in all four Shape things.

BRAD: It’s a method, not a procedure. And they’re classes, not things.

LARRY: Whatever. It’s a stupid design. You have to maintain four different rotate “methods”. How can that ever be good?

BRAD: Oh, I guess you didn’t see the final design. Let me show you how OO inheritance works, Larry.

You can read this as, “Square inherits from Shape”, “Circle inherits from Shape”, and so on. I removed rotate() and playSound() from the other shapes, so now there’s only one copy to maintain.

The Shape class is called the superclass of the other four classes. The other four are the subclasses of Shape. The subclasses inherit the methods of the superclass. In other words, if the Shape class has the functionality, then the subclasses automatically get that same functionality.

Brain Power

Time to pump some neurons.

You just read a story bout a procedural programmer going head-to-head with an OO programmer. You got a quick overview of some key OO concepts including classes, methods, and attributes. We’ll spend the rest of the chapter looking at classes and objects (we’ll return to inheritance and overriding in later chapters).

Based on what you’ve seen so far (and what you may know from a previous OO language you’ve worked with), take a moment to think about these questions:

What are the fundamental things you need to think about when you design a Java class? What are the questions you need to ask yourself? If you could design a checklist to use when you’re designing a class, what would be on the checklist?

A class is not an object.

(but it’s used to construct them)

A class is a blueprint for an object. It tells the virtual machine how to make an object of that particular type. Each object made from that class can have its own values for the instance variables of that class. For example, you might use the Button class to make dozens of different buttons, and each button might have its own color, size, shape, label, and so on.

The Guessing Game

Summary:

The guessing game involves a ‘game’ object and three ‘player’ objects. The game generates a random number between 0 and 9, and the three player objects try to guess it. (We didn’t say it was a really exciting game.)

Classes:

GuessGame.class Player.class GameLauncher.class

The Logic:

1. The GameLauncher class is where the application starts; it has the main() method.

2. In the main() method, a GuessGame object is created, and its startGame() method is called.

3. The GuessGame object’s startGame() method is where the entire game plays out. It creates three players, then “thinks” of a random number (the target for the players to guess). It then asks each player to guess, checks the result, and either prints out information about the winning player(s) or asks them to guess again.

BE the compiler

Each of the Java files on this page represents a complete source file. Your job is to play compiler and determine whether each of these files will compile. If they won’t compile, how would you fix them, and if they do compile, what would be their output?

A

class TapeDeck {

  boolean canRecord = false;

  void playTape() {
    System.out.println(“tape playing”);
  }

  void recordTape() {
    System.out.println(“tape recording”);
  }
}

class TapeDeckTestDrive {
  public static void main(String [] args) {

    t.canRecord = true;
    t.playTape();

    if (t.canRecord == true) {
      t.recordTape();
    }
  }
}

B

class DVDPlayer {

  boolean canRecord = false;

  void recordDVD() {
    System.out.println(“DVD recording”);
  }
}

class DVDPlayerTestDrive {
  public static void main(String [] args) {

    DVDPlayer d = new DVDPlayer();
    d.canRecord = true;
    d.playDVD();

    if (d.canRecord == true) {
      d.recordDVD();
    }
  }
}

Pool Puzzle

Your job is to take code snippets from the pool and place them into the blank lines in the code. You may use the same snippet more than once, and you won’t need to use all the snippets. Your goal is to make classes that will compile and run and produce the output listed. Some of the exercises and puzzles in this book might have more than one correct answer. If you find another correct answer, give yourself bonus points!

Output

Bonus Question !

If the last line of output was 24 instead of 10 how would you complete the puzzle ?

public class EchoTestDrive {
  public static void main(String [] args) {
    Echo e1 = new Echo();
    _________________________
    int x = 0;
    while ( ___________ ) {
      e1.hello();
      __________________________
      if ( ____________ ) {
        e2.count = e2.count + 1;
    }
    if ( ____________ ) {
      e2.count = e2.count + e1.count;
    }
    x = x + 1;
  }
  System.out.println(e2.count);
 }
}

class ____________ {
  int _________ = 0;
  void ___________ {
    System.out.println(“helloooo... “);
  }
}

A bunch of Java components, in full costume, are playing a party game, “Who am I?” They give you a clue, and you try to guess who they are, based on what they say. Assume they always tell the truth about themselves. If they happen to say something that could be true for more than one of them, choose all for whom that sentence can apply. Fill in the blanks next to the sentence with the names of one or more attendees. The first one’s on us.

Pool Puzzle

public class EchoTestDrive {
  public static void main(String [] args) {
    Echo e1 = new Echo();
    Echo e2 = new Echo( ); // correct answer
    - or -
    Echo e2 = e1; // bonus “24” answer
    int x = 0;
    while ( x < 4 ) {
      e1.hello();
      e1.count = e1.count + 1;
      if ( x == 3 ) {
        e2.count = e2.count + 1;
      }
      if ( x > 0 ) {
        e2.count = e2.count + e1.count;
      }
      x = x + 1;
  }
  System.out.println(e2.count);
}

___________________________________________________________

class Echo {
  int count = 0;
  void hello( ) {
    System.out.println(“helloooo... “);
  }
}

Who am I?