Object-Oriented Design of Frogger

Object-Oriented Design of Frogger

As we have seen above, when we design a class, we create a model of some object in the real world. The key points were that:

• Instance variables and constants represent properties.
• Methods represent behaviors
• Layered abstractions allow you to write simple methods that delegate to lower-level abstractions

We also mentioned that you need to distinguish those parts of the real world that you want to model from those that you do not.

Now, recall frogger.

First, what objects appear in the frogger game?

• Frog
• Highway
• Cars, trucks, etc.

Frog

Let's focus on the frog initially. What are the properties of a frog?

• Appearance
• Location
• Whether it is alive or not

How do we represent these? With instance variables.

What are the behaviors of a frog?

• It can hop
• It can say ouch (die)
• It can be reincarnated in the original location

How do we represent these behaviors? With methods.

Let's also think about whether we need getters and setters for our instance variables. Should we allow other classes to change the appearance of the frog? No. Should they be able to access the appearance? Probably not necessary. What about location? Again, we probably don't want any other classes to set the location arbitrarily. Instead our hop and reincarnate methods will move the frog in more controlled ways. What about setting its alive/dead status? Well, when a car hits the frog, we probably want the car to tell the frog it is dead. The frog becomes alive again when it is reincarnated. Is it useful for other classes to know if a frog is alive or not? Maybe cars should interact differently with alive and dead frogs. So, we probably do want an accessor method for the aliveness property.

Finally, we need to think about how we will construct a frog. We must give each instance variable a value. In some cases, we need information outside of the frog to determine reasonable values for those instance variables. How do we communicate that information to the frog? By passing parameters to the frog constructor. How will we initialize each instance variable?

• The location is dependent upon the size and location of the highway
• All frogs start out alive so we can initialize that variable to be true
• What about the appearance. We will represent the frog with a graphics file in the png format. We can keep the URL for the image in the Frog class.

We have now figured out a lot of pieces of the Frog class. Let's see what we have so far:

   class frog(...) -> Frog {
      def frogImage: Graphic2D (from drawableImage)
      var isAlive: Boolean is readable := true  // readable means generates method

      method hopToward (??what goes here??)-> Done{}
  
   
      method reincarnate (??what goes here??) -> -> Done {
          isAlive = true;
          anything else?
      }
       
      method kill (??what goes here??)  -> Done {
          alive = false;
          ??anything else??
      }
       

}

Questions about the design so far:

• Should Frog inherit graphicApplication? No, it doesn't handle user input. Is it animated? No, it is not a self-animated object.
• Why do we use isAlive, not alive? It turns out that for boolean defs and instance variables, the getter (i.e., accessor) is normally named isFoo (where foo is the name of the information accessed). Often, there are two setters: one sets it to false and one to true. In this case, no parameters are needed. Are there setters of the alive boolean in our design? Yes, kill and reincarnate.
• All the methods listed above exemplify user visible behavior but will other classes need them? To understand this, we need to think about how these methods will be used.
  • When would we create a frog? When the program starts.
  • When would hop be called? When the user clicks the mouse.
  • When would kill be called? When the car hits the frog.
  • When would reincarnate be called? When the user clicks below the highway and the frog is dead.
  • When would kill be called? When the car hits the frog. Hey, that's the same time we would call sayOuch. Let's combine them into one method so that we only need to call one method when the car hits the frog. We can remove the sayOuch method and change kill to:

        method kill (??what goes here??)  {
           isAlive := false;
           add code to say ouch
           ??anything else???
       }
    

Are we done with the design of Frog? Probably not. As we think about what we need to do to implement these methods we are likely to uncover more details. But we have designed a good abstraction. Now is a good time to move on to another part of the problem.

Vehicle

We can go through the same exercise with the Vehicle class thinking about its properties and its behaviors. What are its properties:

• Appearance
• Location
• Speed
• Direction

What are its behaviors:

• It moves at a constant speed
• It might kill the frog
• It disappears when it reaches the end of the highway

What kind of thing is a vehicle? It is self-animated; it moves without requiring user input. How do we implement such things? By importing and using module "animation". How do we animate an object

• The initialization of the class creates and saves information that it needs later to run
• The while method of animator animates the object. We follow a slightly different template for this run method:

        animator.while {not at end of highway} pausing{...} do {
           move a little
        } finally {
           remove it
        }
    

This design provides all the behavior we want except for killing the frog. How will we do that? Whenever we move the car, we should check to see if it hit the frog? How does the Vehicle know where the frog is? It doesn't. We need to communicate this information to the Vehicle. When should we tell it about the frog? The only time we interact with an animated object is when we create it, so we have to tell it about the frog then. How does that information get to the while method? We save it in an instance variable. In this case the frog instance variable is not really a property of the vehicle but it is information that the vehicle needs to know in order to give us the behavior we want. This is an example of how we need to not just understand the object in isolation but its context in the larger program to design it correctly.

Lane

Now, where do vehicles come from? They are a lot like the falling leaves that we saw. There are many of them on the screen at once. How did we create falling leaves? With a tree class. The tree class was itself an animated object that continuously generated leaves. We want the same thing here - something that will continuously generate vehicles. What is that class? A highway?

Watch the cars driving across the screen. What do you observe? They drive in lanes. Some lanes go one direction; some go the other. Different types of vehicles drive in each lane. All the vehicles in a lane go the same speed, but the vehicles in different lanes go at different speeds. In short, there are similarities among the vehicles in a lane and differences when we look at different lanes. How can we capture that? By creating a laneFiller class.

What are the properties of laneFiller?

• Location for creating cars
• Speed for the cars
• Appearance of cars
• Direction of cars

What is its behavior?

• To create cars. That's all.

Let's think carefully about what the parameters to the laneFiller constructor should be. Recall that we need to initialize all the instance variables. As a result, we need parameters describing:

• The location where cars start in the lane
• The speed of the cars (since we want each lane to use a different speed, we must compute the speed outside of the Lane and tell it)
• The image for the cars (again because we want the lanes to be different)
• The direction of the traffic

What kind of class is laneFiller? It's another animated object. What does it do? It creates Vehicles:

    animator.while {??what???} pauseVarying{... } do {
       create a vehicle
    }
   what do we do when we are done?

How do we create a vehicle? We call its constructor. What information does the Vehicle constructor need? Appearance, location, speed, direction, and the frog. The laneFiller already received all of this in its constructor except for the frog. Where does it get information about the frog? It needs to be communicated to the laneFiller. How? In the class parameter. So, we need to have a Frog parameter in our laneFiller class. The frog can then be passed to the Vehicle constructor in the Lane's run method.

Handling user input

We need one more class to make our program complete. We need to handle the user input. What user input do we care about? Just mouse clicks. We call this class Frogger. Its responsibility is to get the program started and then call the appropriate methods when the user clicks the mouse. What kind of object is it? It is our familiar friend, an object that inherits graphicApplication.

Object-Oriented Design of Frogger