CSCI A201/A597 and I210
Lecture Notes Twenty-Five

Second semester 2000-2001

Brief summary of the class extension mechanism. Applets.

The format is different today.

Who cares.

Exactly. Let's keep going. That's my Point of view too.

We first defined class Point.

A Point has a position (x, y).

class Point {
  int x;
  int y; 
}

These are the features of any Point object:

an x coordinate, and
a y coordinate, together defining the position of the Point.

A Pixel is a Point with Color.

In Java this is easy to write:

class Pixel extends Point {
  Color c; 
}

The features of a Pixel are three:

an x coordinate (which is an int)
a y coordinate (which is an int)
a Color, call it color

This set of features is the union between the features of a Point and the one new feature that class Pixel is defining, in other words:

That is the resulting blueprint (for Pixel) is a superposition of the two descriptions.

That's fine, but set union means that names should be kept distinct.

We'll come back to this in a second.

How do we use Point and Pixel?

Nothing unusual. We use new and expect the blueprints to define the resulting structures.

// somewhere in a method... 
Point a = new Point(); 
Pixel b = new Pixel(); 
a.x = 2; 
a.y = -10; 
b.x = 3; 
b.y = 24;
b.color = Color.blue;

Notice that the Color class is defined in the java.awt package.

Next we asked: have you ever seen a Horse?

The answer was: yes.

Can you describe a Horse?

The answer was: that's actually quite complicated.

OK, so fortunately we know what we're talking about:

class Horse {
  // lots of features ... 
}

Next we asked: have you ever seen a Unicorn?

The answer was: no.

Can you describe a Unicorn though?

Everybody said: yes, that's easy.

class Unicorn extends Horse {
  Horn h; 
}

So we had the following situation:

everybody has seen horses, but nobody felt it was easy to describe them
nobody has seen unicorns, but everybody thought it was easy to describe them

That's because we factored out the Horse.

Now we said: let's write a play with horses and unicorns.

In our play we could have:

Horse h = new Horse(); 
Unicorn u = new Unicorn();

Both h and u are special kinds of binoculars.

If you put them on you should see the features that their type is defining.

So h.mane and u.mane make sense.

So does u.horn but h.horn doesn't.

For this reason it's not adequate to say:

Unicorn g = new Horse();

It is OK, however, to ignore some features, for the sake of being more general.

From our description it follows that all Unicorns are Horses.

That's called polymorphism.

So writing something like this is acceptable:

Horse z = new Unicorn();

You can never access the Horn with z but sometimes you don't even need that.

We could come up with the following similar example:

class Shape {
  // two coordinates 
} 

class Circle extends Shape {
  // add a radius 
}

class Rectangle extends Shape {
  // add a width and a height 
} 

class Triangle extends Shape {
  // add two other points relative to location 
}

Why is this useful?

If you want to create an array that can store

Circles,
Triangles, and
Rectangles,

the only you can do that is by relying on their generality as Shapes.

Shape p[] = new Shape[100];

I've got room for 100 such shapes (circles, triangles, or rectangles).

There's no other way around it, as far as arrays are concerned.

Now we want to explore the name collision problem.

Consider this example:

class Horse {
  void neigh() { System.out.println("Horse: Howdy!"); } 
} 

class Unicorn extends Horse {
  void neigh() { System.out.println("Unicorn: Bonjour! "); } 
}

Unicorn is listing a feature: neigh.

If Horse had not had it already listed things would've been easy.

But Horses already know how to neigh. They say: "Howdy!".

So Unicorns redefine the feature by saying "Hello!" in French.

That's called overriding.

The mechanism is that no matter how you look at a Unicorn,

as the Unicorn it is, or
as the Horse it is

you are guaranteed to obtain the French greeting out of it.

Here's the proof:

frilled.cs.indiana.edu%cat Ionesco.java
class Horse {
    void neigh() { System.out.println("I am a Horse: Howdy!"); }
} 

class Unicorn extends Horse {
    void neigh() { System.out.println("I am a Unicorn: Bonjour! "); }
} 

class Ionesco {
    public static void main(String[] args) {
	Unicorn a = new Unicorn(); 
	Horse   b = new Unicorn(); 
	a.neigh(); 
	b.neigh();

	Horse c = new Horse(); 
	c.neigh(); 

    } 
} 
frilled.cs.indiana.edu%javac Ionesco.java
frilled.cs.indiana.edu%java Ionesco
I am a Unicorn: Bonjour! 
I am a Unicorn: Bonjour! 
I am a Horse: Howdy!
frilled.cs.indiana.edu%

That's all we need to know before we go into applets.

Here's the basic framework of an applet:

import java.applet.*;
import java.awt.*;

public class Simple extends Applet {
  public void paint(Graphics g) {
    for (int i = 0; i < 20; i++) {
      g.drawString("This is a test.", 20 + 10 * i, 20 + 10 * i); 
    }
  } 
}

Here's what you do to install it:

frilled.cs.indiana.edu%emacs Simple.java
frilled.cs.indiana.edu%javac Simple.java
frilled.cs.indiana.edu%emacs simple.html
frilled.cs.indiana.edu%cat simple.html
<html><head><title>Testing a simple applet</title></head><body bgcolor=white>
  <applet code=Simple width=200 height=200>

  </applet>
</body></html>
frilled.cs.indiana.edu%appletviewer simple.html

And here it is in action.

Last updated: Apr 12, 2001 by Adrian German for A201

CSCI A201/A597 and I210 Lecture Notes Twenty-Five

CSCI A201/A597 and I210
Lecture Notes Twenty-Five