Week 14: Mon, Nov 26

Fox & Rabbits v2
v3: incrementAge(), etc moved to Animal

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

v2: introduce abstract parent class Animal,
but there's only so much we can move there!

v3: introduce data accessors (abstract in Animal);
these allow us to move more routine methods to Animal
But act() still behaves differently for Foxes and Rabbits

v4: break act() up; extract dissimilar pieces of it
and move the rest to Animal.

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

Version 2 of Fox & Rabbits: inheritance

Review v1 code in simulateOneStep in version 1.

Problem 1: Rabbits run, Foxes hunt.

What other methods could we move to a base class?
To what extent are any methods the SAME? 
Note the problem with different static variables.

Inheritance: should simplify the class (fox/rabbit) 
	*and* the client (simulator)

Animal:
	fields:
		age
		alive
		location
		
	rationale for "protected" visibility, and why it's still a bad idea
		
The change: both shall "act()"
THis actually makes a lot of sense if we think about extensions
"hunt" is a predator-specific verb; "run" is sort of a prey-specific action.

Note thing with extra parameter for foxes.


Note Animal is "abstract"
Look at declaration!

Abstract class v abstract method: 
    Abstract classes almost always have an abstract method. 
    Abstract methods MUST be part of abstract classes.

This means we can't create any Animal objects; only subclasses.

	Other candidates for abstract: Shape, DoME Item
	NOT candidates:		       Room, Game Item
	
=========================================================================

Version 3:

fix things to get more into the Animal class: 
	data accessors
	newBabies
	newLocation
	???
	
General goal: keep as much as possible in the base class

What about moving breeding methods to Animal?
The catch is fields like BREEDING_AGE


Experiments: 
move to Animal:
	canBreed
	incrementAge
	addBabies: need a newAnimal method!
	newLocation()
	
Goal: move as much COMMON BEHAVIOR to base class!
	isolate the parts that represent SPECIALIZED BEHAVIOR.
	
	moved breed() to parent class.

summary of "moving to the parent class"
	v1: nothing
	v2: moved fact that both Rabbits & Foxes act()
	v3: moved lots of low-level accessors
	v4: moved act(), newBabies(), breed()
	
Trick: if a method needs access to class-specific CONSTANTS,
but can otherwise be in the base class, replace the constants
with ACCESSORS. Example: breed()
	
1. interfaces
	Actor class, Ant

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

Wednesday:
summary of "moving to the parent class"
	v1: nothing
	v2: moved fact that both Rabbits & Foxes act()
	v3: moved lots of low-level accessors
	v4 (you): moved act(), newBabies(), breed()

Expanding the inheritance hierarchy:

10.5.1	create Actor class, from which are derived Animals and Hunters (new).

p 306, exercise 10.46: hunters do not feed and do not breed
move at random, fire random shots (at neighbors?)

10.5.3: MULTIPLE inheritance!

Some Actors may be Drawable, some (plankton, weather, ant etc) may NOT.

p 290: Actors act, Drawables get drawn. Some are both. 

Inheritance;
	* specifies an Interface: what methods subclasses will have (specifies subtype)
	* allows base class to specify default methods & data
	
Interface: 
	* just the first one above
	
Loop on page 302:
	for (Object item: actors) {
	    if (item instanceof Drawable) {
	        Drawable drawitem = (Drawable) item;
	        drawable.draw();
	    }
	}

10.6: INTERFACEs

public interface Actor {
    void act(Field current, Location loc, Field updated);
}

Notes:
	no "public" necessary
	no "abstract" necessary
	works like a class with all abstract methods: 
		can inherit from it as usual
	Can also "implement" it:
	
	public class Animal implements Actor {
	   ...
	}
	
What good are interfaces?

Classes:
  1. allow us to inherit code
  2. act like a type
  
interfaces DO NOT have 1, but they DO provide 2

Example: can still have an ArrayList<Actor>, 
and can have a parameter List<Actor>


p 296: creating a SimulatorView interface

	
Abstract classes v Interfaces
Both specify an interface (a set of methods).
If all the methods of the abstract class are themselves abstract,
and there are no fields (likely if all methods are abstract),
then an Interface would be clearer.

But often (eg with Shapes, Dome_Item) the base class can be abstract,
but it *does* contain fields and non-abstract methods.

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





==================================
Friday:
(just started demo of ImageViewer on Wednesday)

Chapter 11: GUIs

In this (final) chapter we will see lots of:
* polymorphism
* interfaces (sort of)

In the DoME project we used polymorphism so we could have mixed items in
a single container. What we're doing here is mostly a matter of getting
a "pre-written" library to work with our new features.

	JPanel: tracks mouse, keyboard, & other events
	dispatches events to correct recipients

Writing for GUIs was really what pushed OOP into the mainstream.
Even in the early days of the macintosh, programmers write programs that
constantly tracked the mouse. 


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

List interface example:

	     List (interface)
	    /           \
	ArrayList      LinkedList
	
	List myList = new ArrayList();
	myList.shuffle()

	myList = new LinkedList()

What is this good for? it allows us to change the implementation
*just* by changing the construction!

Look at javadocs for List

=========================================================
version 0.1: JFrame only
	try commenting out pack
	look up type of frame.getContentPane(): ok, it *is* just Container.


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