CS51 - Spring 2010 - Lecture 9
Exercise 9.11.2: Write a program that creates a ResizableBall centered around the point where the mouse is clicked. A ResizableBall is an animated ball that grows up to twice its original size and then shrinks down to half its size before beginning to grow again. It continues to grow and shrink until the program is stopped. The center of the ResizableBall should never move.
- what type of class will ResizableBall be?
- ActiveObject
- What information does it need to know in when it's created (i.e. what does in the constructor)?
- Location where it is centered (either as two doubles or a Location)
- it's initial size
- How do we make it grow and shrink indefinitely?
- need to change the width and height
- need to recenter the ball
- need to handle the fact that sometimes we're growing and sometimes we're shrinking
look at code guides on the class web page
look at LaundrySorter assignment
- how do we drag objects?
...
FilledRect swatch;
...
- access that variable in onMousePress, onMouseDrag and onMouseRelease
show
ShirtsAndPants demo
- we've seen the TShirt class
- we've added a Pants class that is similar to the TShirt class
- What would we need to change in the code?
- randomly pick a clothing type in the onMouseRelease method
- What complication does this add for dragging?
- we need to declare a variable like above, but what would the type be?
- we have a TShirt object sometimes and a Pants object sometimes
interfaces
- what defines the functionality of a class, i.e what the class does?
- the public methods of that class
- the private methods are only used internally within that class
- interfaces allow us to define WHAT functionality a class must have, but not HOW the functionality needs to be implemented
- What functionality (i.e. methods) do we want for either TShirt or Pants?
- move
- moveTo
- contains
- setColor
- getColor
- removeFromCanvas
- look at Laundry interface in
ShirtsAndPants code
- interfaces are defined similarly to classes, with an interface header and internal method headers, but we do not provide an implementation for any of the methods
public interface MyInterface{
// public method headers followed by a semicolon
}
- To use an interface, a class "implements" that interface.
- add "implements MyInterface in the class header
- the class then must implement ALL of the methods defined in the interface
- Interfaces are a contract for a class, that class must implement the methods
- look at TShirt and Pants classes
- they have "implements Laundry" in the class header
- they define all of the methods required by the interface
- notice if we remove one of the required methods (e.g. by commenting it out), then the compiler will complain because we have not fulfilled our contractual obligation
- So, what good is an interface?
- what do we know about any object that implements an interface?
- we know that it has all of the methods declared
- When you define an interface, just like defining a new class, you are defining a new type
- for example, we can define a variable to be of that type:
private Laundry clothing;
- and then assign it any object that implements that interface
- NOTE: an interface is not a class. An interface defines a new type and what functionality that type has, but does not provide any implementation. You cannot say "new Laundry(..)".
- look at
ShirtsAndPants code
- private Laundry item;
- in begin()
- item = new TShirt(...)
- we can do this because it implements the Laundry interface
- in onMouseRelease()
- notice that we generate a random piece of clothing, either a TShirt or Pants and can assign either to our variable
- for our variable item, we can use ANY functionality defined by the interface
- moveTo
- contains
- setColor
- removeFromCanvas
- why does this work?
- because we defined an interface, we know that all of these methods must be defined
DrawableInterface
- Knowing what you know now, do you think it's coincidence that all of the things we've seen so far have shared methods, like
- move
- moveTo
- setColor
- getX
- Most of the classes inherit from DrawableInterface
Object oriented (OO) design
- decompose your problem into objects
- designing objects
- designing the public part of the class
- what information do I need to know to create the object? (this needs to go in to the constructor)
- what functionality does the object need to support? (these are the methods)
- how will the different object communicate?
- after thinking about this, you may have to revisit your design
- the implementation details
- What state will it need to keep track of?
- constants
- instance variables
- why OO design?
- encapsulation: details that are not important to external users are hidden within a class
- abstraction: allow us to think about higher-level things rather than the low-level details (I want to move this object, I don't want to worry about how that happens)
- how do computers work?
- because of encapsulation, you don't need to know, but you can still use them
- complexity: by breaking it into objects, you only need to worry about one small piece at a time
Frogger
- read the entire description before doing anything!
- one of the most challenging labs, so we're giving you an extra day
- Let's roughly map out the classes/design for Frogger
- What are the classes?
- Frogger extends WindowController
- Frog
- Vehicle extends ActiveObject
- Lanes (the road)
- Frog class:
- What is the functionality/behavior?
- move
- be killed
- be reincarnated
- What state will it need to keep track of?
- location
- whether it's alive
- image
- Vehicle class
- What is the functionality/behavior?
- run method that moves the car along
- kill the frog
- the Frog and Vehicle classes will need to communicate
- this is similar to the Box and the Ball
- What state will it need to keep track of?
- location
- image
- Lanes class
- What is the functionality/behavior?
- generate the vehicles (similar to the Tree class in the FallingLeaves example)
- What state will it need to keep track of?
- speed of the cars in its lane
- location
- image
- design process is iterative and sometimes done at different levels of detail