1. Object Oriented Animals (DA243 0708)

2. Code of conduct

3. Approach

4. Schedule

4.1. Week 1: Introduction

  • My expectations
  • Your expectations
  • Armed to the teeth: IDE (JBuilder)
  • Hello World made easy. A showcase.
  • Read your favorite Java book, find out what an object, a class, a method and an instance variable are. And filling out the following "Who am I" form:

    What I do Who I am
    I am compiled from a .java file class
    My instance variable values can be different from my buddy's values
    I behave like a template
    I like to do stuff
    I can have many methods
    I represent a ''state''
    I have behaviors
    I am located in objects
    I live on the heap
    I am used to create object instances
    My state can chage
    I declare methods
    I can change at run time
  • How would you implement a system that does the following:

    There will be shapes on a GUI, a square, a circle and a triangle. When the user clicks on a shape, the shape will rotate clockwise 360 degrees (i.e., all the way around) and play an WAV sound file specific to that particular shape.
    write a proposal in plain English how such a system should be implemented in an object oriented way. No, no Java source code please. But explain why you think your solution is particularly good. When you try to write why, think of the following terms: reusable, robust, readable, extendable, encapsulation ...

4.2. Week 2: Better living in Objectville: A puppy is born

  • Understanding objects
  • Well-encapsulated dogs
  • How Objects behave
  • Life and death

    Source code: Zoo1.zip

  • Questions
    1. What's the big deal about encapsulation?
    2. What happens if the argument you want to pass to a method is an object instead of a primitive?
    3. Can a method declare multiple return values? Or is there some way to returen more than one value?
    4. Does one have to do something with the return value of a method? Can it be ignored?
    5. Guess the output of the following code (You may try out if you want:)

         1   String a = new String("Hello");
         2   String b = new String("Hello");
         3   Foo c = a;
         4   if (a == b) {System.out.println("a == b");}
         5   if (a == c) {System.out.println("a == c");}
         6   if (b == c) {System.out.println("b == c");}
  • Develop a small game: Sink a Unit
    • It's you against the computer, but unlike the real Battleship game, in this one you don't place any ships of your own. Instead, your job is to sink the computer's ships in the fewest number of guesses. Oh, and we are not going to sink ships. We kill units.
    • Goal
      Sink all of a computer's Units in the fewest guesses.
      When the game program is launched, the computer places 2 Units in 10 virtual cells. Imaging a floor of 10 rooms, and a Unit occupies 3 neighboring rooms on this floor. When that's complete, the game asks for your first guess.
      • SinkAUnit.png

      How you play

      You don't have to build a GUI. Let's work from the command line. Here is a possible scenario:

        c:\> java SinkAUnit
        Enter a guess: 1
        Enter a guess: 5
        Enter a guess: 6
        Enter a guess: 4
        Enter a guess: 3
        kill! You sunk Communication Unit!
        Enter a guess: 7
        Enter a guess: 8
        Enter a guess: 9
        kill! You sunk Mobility Unit!
        You sunk all the two units with 8 guesses. Not bad.
      • Here is my design of the Unit class:

           1 public class Unit {
           2   int[] locationCells;
           3   int numOfHits = 0;
           5   public void setLocationCells(int[] locs) {
           6     locationCells = locs;
           7   }
           9   public String checkYourself(String stringGuess) {
          10     int guess = Integer.parseInt(stringGuess);
          11     String result = "miss";
          12     for (int i = 0; i < locationCells.length; i++) {
          13       if (guess == locationCells[i]) {
          14         result = "hit";
          15         numOfHits++;
          16         break;
          17       }
          18     }
          19     if (numOfHits == locationCells.length) {
          20       result = "kill";
          21     }
          22     System.out.println(result);
          23     return result;
          24   }
          25 }
          26 }

        To get the user input from the command line, I have a InputHelper class:

           1 import java.io.*;
           3 public class InputHelper {
           4   public String getUserInput(String prompt) {
           5     String inputLine = null;
           6     System.out.print(prompt + " ");
           7     try {
           8       BufferedReader br = new BufferedReader(
           9           new InputStreamReader(System.in)
          10           );
          11       inputLine = br.readLine();
          12       if (inputLine.length() == 0) {
          13         return null;
          14       }
          15     }
          16     catch (IOException ioe) {
          17       System.out.println("IOExecption: " + ioe);
          18     }
          19     return inputLine;
          20   }
          21 }
      Your task
      1. Prepare the Unit class ( I have already done for you ).
      2. Complete the following test class to test the Unit class

           1 public class TestDrive {
           2   public static void main (String[] args){
           3     Unit unit = new Unit();
           4     int[] locations = {2, 3, 4};
           5     unit.setLocationCells(locations);
           6     //..... complete this code
           7   }
           8 }
        try out whether the Unit prints and returns right message with different guess, for example "2", "5", "7", etc.
      3. Write a complete game, which randomly places a unit in 3 neighboring cells of the 10 cells. The user guesses where the unit is and tries to sink it. You might find the following piece of code helpful when placing the unit randomly:

           1        int randomNum = (int) (Math.random() * 8);  //why 8?
           2        int[] locations = {randomNum, randomNum+1, randomNum+2};
      4. A unit should have a name, for example, "Communication", "Mobility" (Do not try to sink "Home"!). improve the code of the class Unit to incorporate a name. Try to sink the Unit Communication.
      5. Improve your game to place two units in the cells. try to sink both of them.
      6. Analyze the code of the class Unit. Is there any problem? what if the Unit has been hit three times at the same cell?
      7. Did the princple of encapsulation help in developing this game? Where and when?

4.3. Week 3: Serious Inheritance and Polymorphisms: Bark, but bark different

  • Abstract class: Dogs and cats are all animals. Animal is an abstract concept.
  • Inheritance: Cats and Dogs do eat and grow as all other animals do.
  • Overriding: Barking is an important part of our cultural identity. We don't talk. We bark.
  • Interfaces: Some Dogs and cats are friendly enough to be a pet. A pet does not have to be an animal and an animal does not have to be a pet...Mad.
  • The most generic in the Zoo: Object.

Source code: Zoo2.zip

  • Questions
    1. What's the big deal about inheritance?
    2. How do you know when a class should be abstract and when should be concrete?
    3. How do you know whether to make a class, a subclass, an abstract class and an interface?
  • Backup your zoo first, then try the following:

    1. Dogs and cats are mammals. But ducks are not, they are birds. All the mammals and the birds are animals. Try to refactory the inheritance tree to reflect these concepts.

    2. Add a duck called "Donald" to your zoo and make it talk like a duck.
    3. Pack your zoo and send me the zip file.
    4. Restore your zoo, so that next week we still have the same code base.

4.4. Week 4: Powerful composition: Armed and Dangerous

  • Composition: Dogs have got a body, and cats too.They run around in the Zoo.
  • Interface: We feed pet animals, and they grow.


  • Backup your zoo first, then try the following:

    1. Give two eyes (buttons) to each animal's body.
    2. When any of the eyes are clicked, the animal says "ouch!".
    3. Try to invent some food only for Ducks.
    4. Change the BuffetTable so that the duck food can also be offered there.

    5. Feed Donald and let him grow.
    6. Now all the animals get the same body. Try to give a different body to different animals -- Simply use a different background color to represent a different body.
    7. Pack your zoo and send me the zip file.
    8. Restore your zoo, so that next week we still have the same code base
  • Question:
    1. Review the structure we have now. Are there any problems? How could we improve it?

4.5. Week 5: Something is happening: Romeo and Juliet in Objectville

  • Singleton: There is one, but not more than one Zoo.
  • Event handling: Watch out! A dog is barking!
  • Hollywood principle: Do not call us, we will call you.

    Zoo4.zip (updated)

  • What we have done for cats to react on barking dogs:
    • Model all the events in the Zoo as a subclass of Event;
    • Implementing the Zoo as the central place to dispatch the Event;
    • Implementing the Dog to fire the Event;
    • Implementing the cats to receive the events as an EventListener but only letting the cat reacting on the DogBarkingEvent

    But we may also:
    • design a DogListener interface that has a method dogBarking();

    • The cats implements the DogListener interface;

    • Add cats to every dog, and every dog maintains a list of cats who are listening;
    • When dog barks, notifies every registered cat by calling its dogBarking() method.
    Both designs implements the functionality we needed.but which one do you think is better than the other in which cases?
  • Complete the Zoo:
    • Create a new type of event: DogSleepingEvent and DogMovingEvent

    • In case of DogSleepingEvent, cats have parties; if dogs are moving, cats stop partying.

  • When you finish all of the above, think again, and try to answer the following questions:
    • What were the important decisions we have made so far?
    • We programmed. We did not design. If we start over again, given the Zoo (some rough descriptions about cats and dogs and how they interact) as a requirement, how should we design in order to get a clear structure even before we do any coding?
    • Imagine tomorrow you are going to meet your fellow designers and explain the static structure and the dynamic behaviors of your Zoo to them.How would you do it?

4.6. Week 6: Object Reloaded

  • Read online: * Essence of Object Oriented Programming Several chapters of this book by Wampler are available online. Chapter 2 has a very good overview of object-orientation.

  • Download and install Microsoft Visio 2003 (available as a campus software package). You may also want UML 2.0 stencils from Pavel Hruby

  • Try to use visio to draw a UML class diagram that reflects the static structure of your zoo.

4.7. Week 7: Yet Another Language: UML

  • Read the following tutorials. Mind the difference between UML 1.0 and UML 2.0:
  • Draw a use case diagram for the IDPortal. To simplify the task, only consider the the self-evaluation and assessment tasks performed through IDportal.

4.8. Week 8: Yet Another Language: UML (Continued)

  • Lecture: Introduction to UML (II)
    • Class Diagram
    • Sequence Diagram
    • Activity Diagram
    • State Machine Diagram
Homework (for the following two weeks)
  • Read the following tutorials:
  • Write Java Code to reflect the following class structure:
    • ABCDClass.jpg

  • Suppose you are designing an Instant Messaging client (for example called Brilliant Messenger to beat MSN messenger), in the design there is a class called "Buddy", and a "Buddy" has different states (away, busy, dnd, etc).
  • Again we try to beat MSN messenger with our Brilliant Messenger. Suppose you are designing the conversation behavior of a buddy.
  • However we found it to be difficult to really beat MSN messenger, so we try to collaborate with Microsoft. We have no choice but to implement a MSN plugin so that you can talk to your MSN buddies with our Brilliant Messenger. Every buddy from MSN is modeled as an MSNBuddy object, and we maintain them in an MSNBuddyList. To talk with these MSN buddies, we have to present ourselves to MSN Messenger network. We model "my msn account" as an MSNMe class, and every message received from MSNBuddy and sent to MSNBuddy is done by the real BrillantMe through MSNMe.

    • Now, suppose an MSNBuddy who is never in your list initiates a conversation, BrillantMe may accept the conversation or may not. If the conversation goes well, BrillantMe may find it interesting to keep this buddy in the MSNBuddyList. Draw a sequence diagram to show the communication among MSNBuddlyList, MSNBuddy, MSNMe, and BrilliantMe.

  • Read the following tutorials:
  • Suppose you are designing an Instant Messaging client (for example called Brilliant Messenger to beat MSN messenger), in the design there is a class called "Buddy", and a "Buddy" has different states (away, busy, dnd, etc). Draw a state diagram for this "Buddy" class.
  • Again we try to beat MSN messenger with our Brilliant Messenger. Suppose you are designing the conversation behavior of a buddy. Draw an activity diagram to show how a conversation should be started, preceded and ended.

4.9. Week 9: Desgin Patterns (I)

  • continue the tasks from week 8

4.10. Week 10: design Patterns (II)

  • Lecture: A layer up: Introduction to desgin patterns
  • Assignment evaluation.
  • Write a short summary, not more than 3 pages of A4, including:
    • what have you learned from this assignment
    • Do you think object orientation is a good idea? why? or why not?
    • In which ways can it help (or harm) you as a designer? Can you give an example (no software design please)?
    • Which parts of this assignment do you like most?
    • In which ways could we have done better during this assignment?

5. Homework Answers

JunHu: ObjectOrientedAnimals/200802 (last edited 2008-10-03 20:20:09 by localhost)