04.04.2013 Views

Processing: Creative Coding and Computational Art

Processing: Creative Coding and Computational Art

Processing: Creative Coding and Computational Art

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

PROCESSING: CREATIVE CODING AND COMPUTATIONAL ART<br />

330<br />

//subclass 2<br />

class Elf extends Creature{<br />

void castSpell(){<br />

println("Gotta make the cookies");<br />

}<br />

}<br />

/* game engine--with embedded superclass<br />

reference in the addCreature() method */<br />

class Engine{<br />

void addCreature(Creature c){<br />

c.castSpell();<br />

}<br />

}<br />

In the example, the Ogre <strong>and</strong> Elf classes each extend the Creature class. Through this<br />

inheritance relationship, any Ogre <strong>and</strong> Elf objects instantiated will now also be of the secondary<br />

type Creature. Thus, it would be perfectly legal to assign new Ogre <strong>and</strong> Elf objects<br />

to variables declared of type Creature.<br />

Creature o = new Ogre();<br />

Creature e = new Elf();<br />

However, as you continue to exp<strong>and</strong> this example, you’ll want the Ogre <strong>and</strong> Elf objects to<br />

be assigned to variables of type Ogre <strong>and</strong> Elf, respectively—so if you tried using the preceding<br />

superclass assignment lines (which would work for now), make sure you put them<br />

back to what they were:<br />

Ogre o = new Ogre();<br />

Elf e = new Elf();<br />

This capability of unrelated objects (created from different classes) to have a relationship<br />

through a common parent class (which each class extends) allows you to create moreflexible<br />

programs. For example, if you create a game that includes the Ogre <strong>and</strong> Elf creatures,<br />

inside the game engine you’d either have to hard-code reference variables for each<br />

of the creatures, or use a common extended class. For only two creatures, either option<br />

might be fine. However, what if your game included 20 creatures, or even the capability<br />

for players to create their own creatures? The last thing you’d want to do is to keep going<br />

into your game engine code <strong>and</strong> adding new reference variables every time a player created<br />

a new creature. Rather, by including a common superclass reference variable in your<br />

engine, you could simply require players creating a new creature class to extend your base<br />

Creature superclass. This would allow your game to scale up, without you’re ever having<br />

to touch the game engine source code.<br />

Besides including a reference to the superclass in your game engine, you’d also need common<br />

methods within the Creature superclass <strong>and</strong> all the individual subclasses. In my last<br />

example, notice the common castSpell() method within the Creature superclass <strong>and</strong><br />

both the Ogre <strong>and</strong> Elf subclasses. These methods have identical signatures (same name<br />

<strong>and</strong> parameter list). However, their implementations (the code between the curly braces<br />

of the methods) are different. As I mentioned earlier, one of the benefits of inheritance is

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!