*******************************************************************************
0) Administrative
- hw: 13.4-13.6
- hold onto A5 designs until end; take A5 handout
- no codelab: design concept, not coding

1) Last time- finished arrays
- quiz next time

2) Go over 13.1-13.3 in groups

3) Highlights

	A. When you use inheritance:
		- when you have two or more classes that have lots in common
		- and they can both be described as specific kinds of one thing
		- or when you need both a general and specific kind of thing
	   How you create it:
		- you make a class to represent the general thing (superclass)
		- it has all the common stuff: data and methods
		- any specific classes inherit it, and can add their own stuff
		  or override the stuff they inherited with their own versions
	   The relationship between superclass A and subclass B:
		- every object of B is also an object of A
		- anything that an object of A has, an object of B has
		- an object of B could have some stuff that an object of A doesn't
		- an object of B could override some stuff it got from A
	   The advantages/disadvantages
		- you write less code: only once instead of multiple times
		- adding more specific kinds is easy and fast
		- but there's stuff in a class that isn't immediately visible

	B. What gets inherited
		- all non-private members (not constructors)
		- private ones do exist, but aren't accessible
		- could use public mutators, or could make data public
		- but we don't like this, so there's another visibility
		- protected: visible to subclasses, but not unrelated classes (#)
		- note that no visibility = package (basically public)

	C. Example: BankAccount (don't write down actual code)
		- all bank accounts have to do some similar things
		- here's a superclass that contains those things
		- what would a subclass SavingsAccount need to add? (interest)
		- here's the subclass: what does it get?
		- note it has a constructor too: details next time
		- what would a subclass CheckingAccount need to add? (withdr. fee)
		- what methods aren't good enough to deal with fees? (withdraw)

	D. Overriding methods
		- replacing inherited ones that are too general
		- write method with same header (greater visibility is ok)
		- put your specialized stuff in it
		- if you want to use the general one, use super.method()
		- call withdraw(): the most specific available version runs
			* if it's a BankAccount object, the general one
			* if it's a CheckingAccount object, the specific one
		- here's the subclass

	E. Polymorphism: taking several shapes
		- can have references to BankAccounts that really store subclasses
		- in AccountTest, we have an array
		- trace which calls get run at each line
		- dynamic binding: decides which method at runtime, dynamically
		- so the same method call can call different methods
		- sometimes you need to figure out what kind of instance it is
		- endOfMonth method uses "instanceof" operator to cast
			* you have to cast, or you'll get an error
		- but the report one is polymorphic again
			* no need to cast because BankAccount has a report method
			* this still uses the specific versions, though

4) Exercises

	A. Do inheritance for Phantom and JavaMuncher
		- use back of A5 handout and divide into 3 pieces
		- create Actor (or whatever): what do they both need?
		- what should the others add? what should they override?
		- put visibilities on everything

	B. Polymorphism in timerEventHeard method
		- could be PhantomsMovedEvent or PhantomsAlmostUneatableEvent
		- have to do different things in each case
		- write code/pseudocode to do this

		public void timerEventHeard(TimerEvent event) {
			if (game is not over) {
			    if (event instanceof PhantomsMovedEvent)
				// move the phantoms
			    if (event instanceof PhantomsAlmostUneatableEvent)
				// make the phantoms uneatable
			}
		}

	C. The "colliding with other actor" method
		- we have a method in the Point class that tells whether an image
		  at this point overlaps with an image at that point (draw)
		- we have this method: what's polymorphic about it?

		public boolean isRunningInto(Actor actor) {
			return (this.location overlaps actor.location)	
		}

	D. Overriding the move method
		- the generic move in actor

		public void move(int dx, int dy) {
			location.moveBy(dx,dy);
			sequencer.nextImage();
    		}

		- the more specific one in JM

		public void move(int dx, int dy) {
			if (dy < 0) sequencer.setSequence( the 'up' one );
			if (dx < 0) sequencer.setSequence( the 'left' one );
			if (dx > 0) sequencer.setSequence( the 'right' one );
			if (dy > 0) sequencer.setSequence( the 'down' one );
			super.move(dx,dy);
		}

5) Summary
- how inheritance works
- overriding members and member accessibility
- polymorphism and dynamic binding

*******************************************************************************