Week 11: Week of Nov 5

Shapes
Game

We saw Friday (and you will see today) that we could take the separate 
Circle, Rectangle/Square, Triangle shapes, and create a common base class MyShape
that contained most of the methods:

    * makeVisible
    * makeInvisible
    * moveRight
    * moveLeft
    * moveUp
    * moveDown
    * moveHorizontal(int distance)
    * moveVertical(int distance)
    * slowMoveHorizontal(int distance), slowMoveVertical(int distance)
    * changeColor
    * erase (somewhat surprisingly, this is not shape-specific.) 
	
The draw() method must be implemented separately for each shape.
However, it must be present in Shape, as a "stub".

We also saw that MyShape was now:
	* GENERAL enough to hold ANY SHAPE
	* SPECIFIC enough so that we could always invoke draw(), polymorphically.
	
This is the second half of code-duplication-avoidance of inheritance:
code is simplified for the "user" or "client" classes.

===============================================

Here are the other shape-specific methods: 
    * Circle: changeSize(diameter)
    * Rectangle: changeSize(width, height)
    * Square: changeSize(size)
    * Triangle: changeSize(width, height) 

Note that these methods do NOT have anything to do with each other;
they can NOT be called polymorphically.

!!!!!!!!!!!!!!!!!

There's a problem here: Square will inherit changeSize(w,h) from Rectangle.
But if you have a 100x100 square s, and call s.changeSize(100,50),
**it's no longer square**.

How can we fix this? 

=====================================
===============================================

Casting:
	MyShape s;
	if (s instanceof Circle) {
	    Circle c = (Circle) s;
	    c.changeSize(30);		// s.changeSize():  wrong type
	}
	
=============================================================================
=============================================================================
	
Wednesday:

Exam 2 is next Wednesday, Nov 14


Shape is THE classic objects-know-how-to-draw-themselves example.

===============================================

ArrayList and inheritance

Where did we see collections? (Or Object)
	HashMap
	ArrayList
	

=====================================

Game example

How should rooms respond to commands?

Current version:
	Room.respond(command c, ArrayList<Item> inventory)
	
(why inventory??)

Some commands are handled in the main game: this is probably the
right thing. It prevents Rooms from handling things differently.
Though notice that "look" can be made to behave differenly in dark rooms
by having the room override getLongDescription()

TAKE, DROP examples

The GO command is different from all the others.
I used to handle it with a special method, but I've given up on that.
The response is to print something, and maybe return a new Room.

Responses of other commands are simply to print something, and set some
internal state things.

It is *possible* for a non-GO command to move you to another room.

Room response to GO *must* print out description of new room.
But derived rooms almost never need to worry about this, since
if they modify the response to GO they almost always BLOCK the move.

Note that derived classes will call super.respond() a LOT.

Conventions:
	GO first
	don't use else for main alternatives; use return instead.
	

LockedRoom
	overrides GO

===================================================================
====================================================================

Friday:


SerpentRoom
	overrides GO, GIVE,  TAKE SERPENT

Old way: have getExits decide who can go which way.
Problem: it also has to print out the problem (trolls, no key, etc)
which doesn't seem to be a logical place for that in some contexts.


inventory problem:
	natural for take/drop
	sometimes applies to GO (eg need flashlight)
	hard to anticipate when we need it.
	But think of inventory as representing "player data".
	
ValveRoom:
	overrides GO wetdirection, TURN VALVE
Notice static linking of TWO valverooms!!


DustyRoom (north of prepRoom)
	overrides SWEEP

ZooRoom
	overrides get?Description
	respond
	
DarkRoom
	overrides getShortDescription, getLongDescripton
	respond overrides GO, LIGHT, TAKE
	note the check of inventory in getXDescription
	constructor trick!
	Note how anything that's a Light can be lit!!