Processing: Creative Coding and Computational Art

forced to literally implement the interface—meaning add curly braces and fill in the body
of the method. Next, I’ll add a launchArrow(Archer a) method to the Engine class, which
includes a parameter of the Archer interface type. Here’s the completed Engine class:
class Engine{
void addCreature(Creature c){
c.castSpell();
}
void launchArrow(Archer a){
a.shoot();
}
}
The launchArrow() method works the same way as the addCreature() method. When the
launchArrow() method is called, the respective shoot() method implementation (in a
class implementing the Archer interface) will be selected based on what specific type the
more general Archer types evaluate to. Finally, here’s the updated setup() function,
including the new Knight instantiation and launchArrow() method calls:
void setup(){
Creature c = new Creature();
Ogre o = new Ogre();
Elf e = new Elf();
Knight k = new Knight();
Engine eng = new Engine();
eng.addCreature(c);
eng.addCreature(o);
eng.addCreature(e);
eng.launchArrow(e);
eng.launchArrow(k);
}
I want to make one final modification to this example. In the setup() function, I originally
instantiated the Creature object only to help illustrate how method implementations can
be dynamically selected, based on the type of the passed argument. When I passed in a
subclass object, its castSpell() implementation was used, but when I passed in the superclass
object, the castSpell() implementation within the superclass was actually used. In
reality, you generally wouldn’t want to instantiate a Creature object. Instead, you’re only
interested in using the Creature class as a base for more specific creatures.
Java includes the reserved keyword abstract, which can be used to enforce this behavior.
You simply preface the class declaration with the abstract keyword, turning the class into
an abstract class. Here’s the Creature class as an abstract class:
abstract class Creature{
void castSpell(){
println("nothing to say");
}
}
OBJECT-ORIENTED PROGRAMMING
333
8