CSE 131 Module 10: Class Hierarchies
Review studio procedures before
- Form groups of no more than three people.
If your group
is joined by a fourth person, split into two groups of two.
- One of you should log in, launch eclipse, and
open the SVN Repository Exploring perspective:
Window...Open Perspective...Other...SVN Repository Exploring
- Click on the New Repository Location icon (looks like a
gold battery with a green plus sign).
- Copy the following URL using your mouse:
- Change XXXXX to your username that you use to log into cec computers. For example, jdl2.
- Be sure the directory after fall09 is studios and
- Change ZZZZZZ to the word on your sticker.
For example, animal.
- If prompted, type in your name and password.
- If the repository is validated, keep going; otherwise get help.
- Right-click on the project name and Check Out the workspace.
- Return to the Java perspective.
- You will need somebody's lab4 implementation.
Copy and paste a working lab4 package into your studio10 project. Be sure to paste it into the src component of your workspace.
The goal of this studio is to get acquainted with a design for
the BrickBreaker game, and to investigate the use of class extensions to
Go as far as you can with this, and feel free to experiment. Show your work to
TAs as you go and interact with other groups if you have ideas to share or need help.
- Right-click Main and choose Run As ... Java Application.
Play with the paddle a bit and observe its behavior.
- Open the Blob interface and examine the methods defined there.
A class implements Blob so that it can describe the space it occupies
in the game. There is no visualization associated with Blob. Instead,
it is a model for the space occupied by an instance of a class in the game.
- As discussed in class, a BoundingBox is a simple approximation
of the space occupied by an object. It is also a class that
can easily implement Blob. Open BoundingBox and
look at its methods.
- Complete the intersects method as described in class.
One BoundingBox intersects another if any corner of one box
is contained in the other box. You have to test in both directions!
- Run the BoundingBoxTest JUnit test case found in
the gametests package of your workspace.
- Run also the PieceTest JUnit test. It should pass too.
If your test fails because of two Point objects that look
alike but say they're different, this means you have to go to your
Point class from lab 4 and put in a .equals method.
Eclipse will generate that automatically for you. Open the Point
class and go to Source..generate hashcode and equals, and let eclipse generate
the methods based on the instance variables that represent the point's
- Run the Main class again. Now, the Paddle should not
be moving past the walls.
- Add the following methods to BoundingBox:
- boolean isBiggerThan(BoundingBox other), which returns true
if and only if this BoundingBox is bigger (takes more area) than the
- int perimeter() returns the perimeter of the BoundingBox.
- Look at the MovePublisher interface. It is implemented by an object
that can notify other objects (subscribers) when that object moves.
- Look at the Mobile interface. It describes an object that
is both a Blob and a MovePublisher. A MovePublisher can
keep track of any number of MoveSubscribers. When it moves, it notifies
each subscriber that
it has moved by calling the subscriber's observeMove method.
Should a MovePublisher use an array or a list to keep track
of its subscribers?
- The simplest object that brings these concepts together is Piece, which
represents an object that might move and that occupies space in the game.
Open Piece and make sure you understand each of its methods. Ask questions
if something is unclear. In particular, examine
- addMoveSubscriber, which adds another subscriber to the object, and
- setLocation, which notifies all subscribers that the object has moved.
How would you modify setLocation so that it doesn't notify subscribers
if the object's new location is the same as its old one?
- OK let's look at the code from a different viewpoint. When the code begins,
execution starts in Main, which instantiates an instance of Main and
a NIP panel in which objects will be visualized.
- A Controller is also instantiated, and it is responsible for setting
up the visualization and handling the control aspects of the game.
- Main handles all of the mouse interactions, and calls Controller
to carry out the work on behalf of mouse actions.
What exactly happens when the mouse moves? Follow the code from Main
into Controller to see how mouse motions cause the Paddle to change
- Modify Main so that mousePressed calls the appropriate
method in the Controller
to set the Paddle all the way to the left, to the right, or in the middle
Show this to your TA.
- While Piece models an object that takes space, there is no visualization
placed directly in the Piece object. Instead, PieceViz combines
a Piece along with a Graphic that represents the Piece
in the game. The Graphic can be changed at any time by calling the
- How does the PieceViz know that its Piece has moved, and
where is action taken in PieceViz to adjust the visualization?
If you are uncertain, look again at the move publisher and subscriber
- Specific types of PieceViz classes can be established by extending
PieceViz. Take a look at Boundary, which represents the walls
and ceiling of the game. Its constructor uses super to establish its
parent class, PieceViz, by providing it a Piece and a GraphicsPanel.
- The Controller sets up the display that you see by instantiating four
Boundary objects, picking a different color for the floor than the ceiling and
walls. It also sets up the Paddle.
- Change the Paddle instantiation to SlowPaddle and run
the game. Because SlowPaddle extends Paddle, it can be used
anywhere a Paddle is expected, but its behavior can extend the behavior
- Implement ShyPaddle as another extension of Paddle or
of SlowPaddle so that it avoids the cursor (as shown in class).
A child class can cause its parent's definition of a method foo
to execute by calling it as super.foo(...).
Test this by changing Controller so that it instantiates ShyPaddle
in place of Paddle.
- Define a Brick class that extends PieceViz like Boundary
does, but uses a different color.
- Modify Controller so that it places some number of Brick objects
in the game. Make sure they show up in the display. If some are missing, it's likely
you gave them coordinates that caused them to be hidden. Try to place the Bricks
where you want them for the game.
- Take a look at KeepPaddleInBounds. How does it detect when the
Paddle hits a wall, and what does it do about that? Modify its behavior
so that when the paddle hits the wall, something different happens.
- How would you modify the game so that two Paddles could be
deployed some distance apart from each other?
Hint: Instead of having the Controller directly a single
Paddle, consider having it change the location of a Piece.
Each Paddle can be a MoveSubscriber to the Piece.
When the Piece moves (in response to the mouse moving), each Paddle
is notified and can change its location accordingly, using some offset from the
Submitting your work (read carefully)
- Complete the feedback.txt file and be sure to list
your group members' names and ID last-3-digits.
- Answer the other questions in the feedback.txt file.
- You must commit all of your work to your repository. It's best to do this
from the top-most level of your repository, which bears your name and student ID.
- You must have the TA clear you by signing your studio group sheet.
Be sure your names and IDs are written
clearly on the TA's demo sheet.
Last modified 19:55:26 CST 18 November 2009
by Ron K. Cytron