Comp 170 Week 13

Fox-Rabbit

small-grid examination?

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()

Expanding the inheritance hierarchy:

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

Exercise 10.51 (4th ed): hunters do not feed and do not breed; they move at random (each step they choose a new random location anywhere in the field, not necesarily adjacent), they fire random shots (at neighboring foxes?), not necessarily adjacent (though maybe some limit is appropriate).

                  Actor

    Animal            Hunter

Rabbit Fox

10.5.3: MULTIPLE inheritance!

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

    Drawable         Actor

                Animal   Hunter

    Rabbit   Fox   Ant

Ant is the only non-Drawable

See Fig 10.4 (4th ed): 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: itentifies methods

Loop on page 327 (4th ed):

    for (Actor actor : actors) actor.act();
    for (Drawable d: drawables) d.draw();

The latter can also be done like this (because every Drawable is also an Actor)

    for (Actor 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);
}

or

public interface Actor {
    void act(List<Actor> newActors);
    boolean isActive();
}

Notes:
    no "public" necessary
    no "abstract" necessary
    works like a class with all abstract methods:
        can inherit from it as usual (using "extends")
    Can also "implement" it:

    public class Animal implements Actor {
       ...
    }

or

    public class Rabbit extends Actor implements Drawable { ... }

finally,

    public class Hunter implements Actor, Drawable {...}

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>

Interfaces are a form of specification. See the List interface (below).

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.

enum example:

Just so you can read the examples in the book; we won't use them in class.
See book, p 233, and zuul-with-enums-v1

Autoboxing and non-object types
    int x;
    Integer y;
    y = x;
    x = y;
    ArrayList<Integer> AI = new ArrayList<Integer>();
    AI.add(3);
    x = AI.get(0);

Prior to autoboxing, one would have to do
    y = new Integer(x);
    x = y.intValue();

From my Autobox project:
    public void demo()
    {
        // put your code here
        x = 3;
        xI = 5;
        x = xI + 1;
        xI += 1;
        xI ++;
        System.out.println("x=" + x + ", xI=" + xI);
        al2.add(3);
        al2.add(37);
        al2.add(667);
        x = al2.get(1);
        System.out.println("x=" + x + ", xI=" + xI);
    }

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

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. In the early days of the macintosh, programmers wrote programs that constantly tracked the mouse. This was tedious. It was better to have one such program, prewritten, and use inheritance as a way of providing "hooks" for programmer-supplied "handlers".

ImageViewer overview

AWT (Abstract Widget Toolkit) and Swing

version 0.1: JFrame only
try commenting out pack

Note that the contentPane is declared to have static type Container. In fact, Container (or java.awt.Container) is just a particular parent class, acting in some respects like an interface. This lets us add() things (like the label). Here's the hierarchy:

java.lang.Object
  java.awt.Component
      java.awt.Container
          java.awt.Window
              java.awt.Frame
                  javax.swing.JFrame

The actual type returned by JFrame.getContentPane() is in fact Container; this means though that the getContentPane() object is just there for adding elements to. Note that the Container type is not the same as the java.util.List interface, but the add() method works similarly for both.

version 0.2:
    add JMenuBar, JMenu, JMenuItem.
    add a global event listener:
        public class ImageViewer implements ActionListener
        This means that ImageViewer supplies a method actionPerformed(ActionEvent e) (find it!)
        We call addActionListener(this) for all JMenuItem things, to register them. What does this mean?
Note what MenuItems now do: on menu selections, the actionPerformed() method is called by the external runtime system. When we call openItem.addActionListener(this), then whenever the menu item openItem is selected, then this.actionPerformed() is called.

    version 0.2 uses the ImageViewer class as its ActionListener; that is, all menu actions result in a call to the single method this.actionPerformed().

Demo: comment out the "implements ActionListener" line and the two *.addActionListener(this) lines, and see what changes. (The menubar is still there, and still works, but nothing prints now when we choose menu items!)

Old-style event manager: (Applet style)
    windows widgets typically have an OnMouseClick, OnMouseDown, OnMouseMove, etc
    You have your own class that extends that class, and provides its own OnMouseClick, etc, method.
    Any mouseclicks now get handled!


Who can have an addActionListener? What events to the object trigger it? javax.swing.AbstractButton class.

    Some Events and Their Associated Event Listeners

Act that causes the event	Listener type
User clicks a button, presses Enter while typing in a text field, or chooses a menu item	ActionListener
User closes a frame (main window)	WindowListener
User presses a mouse button while the cursor is over a component	MouseListener
User moves the mouse over a component	MouseMotionListener
Component becomes visible	ComponentListener
Component gets the keyboard focus	FocusListener
Table or list selection changes	ListSelectionListener
Any property in a component changes such as the text on a label	PropertyChangeListener
Adjust a "slider" control (or similar)	ChangeListener

Big problem: event dispatch. How does our actionListener() method figure out how to respond to an event?

Better: have each JMenuItem listen for activation, and call its own appropriate method

menuItem is a javax.swing.AbstractButton
addActionListener is a method of class AbstractButton
JMenuItem extends AbstractButton

JLabel, MenuBar do NOT: there is no trigger passed to your program if these are "touched" by the mouse.

Inner classes: classes defined within other classes.

Digression: what about making Rooms inner classes of Game? This solves the inventory-access problem! But it also generally makes a muddle of things; everything is now in one class, Game, which becomes immense.

Demo of imageViewer0-25: new menu item "stuff", inner class StuffListener

    Weirdness: StuffListener is just used once!

    "Anonymous" inner classes: define & create in one place, without a class name

version 0-3: implements anonymous classes!!
    Also, quit() now actually exits instead of printing.
    Specifically for menu actionListeners

Here's the code:
           openItem.addActionListener(new ActionListener() {
                               public void actionPerformed(ActionEvent e) { openFile(); }
                           });

Here's just the defined-and-created anonymous class:
           new ActionListener() {
                               public void actionPerformed(ActionEvent e) { openFile(); }
          }

Now we divide it into definition and creation:

          class AnonyClass implements ActionListener {
                               public void actionPerformed(ActionEvent e) { openFile(); }
           }

           new AnonyClass();

How do we get from (complicated) file formats to a simple model of an image in which all we have to do is access the pixel at location (x,y)??

version 0-4:

Groundwork for displaying images. Keyboard shortcuts for menus

ImagePanel extends javax.swing.JComponent: panel for the image. Note that JComponent differs from java.awt.Component.
    where does repaint() come from, called in ImagePanel.setImage, clearImage?
    It's a method in Component.
Note Component <- Container <- JComponent!

version 1.0:
adds menu of darker/lighter/threshold. These are implemented in OFImage, by darker(), ligher(), threshold(). Look at the code here; they are our first example of actually getting at the pixels! Note also that they are entirely in-place operations.