•An event to spawn cows
•The idea that each cow needs a timer so it has a chance to find players
and attack them
•The idea that the cow needs to not get stuck in the terrain (what if there's
no player nearby?)
•The knowledge that we may need to put a limit on the number of cows to
Try This Yourself
Now go through these questions for the plugin you want to build, and come
up with your own list of things you'll need—your “materials.”
Include things you aren't sure about—there's no penalty if you end up not
Lay Them Out
Before we create the plugin and start writing code, let's think about what
might go where. In other words, will this fit all in one function or even one
class, and if there are several functions or classes, what goes where? If there
are additional classes, what do they need to know about us or each other? If
you've forgotten some details of functions and objects, check back with
Chapter 4, Plugins Have Variables, Functions, and Keywords , on page 43 , and
Chapter 5, Plugins Have Objects , on page 67 , for a refresher.
So here are our questions:
•What goes where? What functions and classes do you need?
•Why do you need this function (or class)? What is it responsible for?
•Who else needs to know about this function or class (if anyone)?
One way of attacking this, especially on complicated plugins, is by using good
old-fashioned index cards. (These are called CRC cards, where CRC is short
for “class-responsibility-collaborators,” invented by our friends Ward Cunning-
ham and Kent Beck.) Divide each card into three parts: a title up top, a list
of things it is responsible for on the left, and other classes it needs to work
with on the right.