Here's more information on it:

Object oriented programming is like volleyball. First, someone out there defines a class called volleyball, with rules, actions, methods, etc., enabling anyone to play a game or "instantiate" (a term specifically created for OOP, meaning "to begin an instance"). As many volleyball games can go on at one time as needed, as space provides, around the world. The game itself is the object "volleyball," created from a specific class called "volleyball" (same name as the object [actually, the object will take the same name as the class]). And, as the rules of the class volleyball change, so too do the games [objects] as they are played [created]. Now, I take my little analogy pretty far in my own head, describing the players as the variables, the serve as a "constructor" (a specific method that creates an object), etc. The one thing, though, that I think is important to realize is that most objects will be slightly different, based on user input, time of day, whatever (because you wouldn't use OOP for anything static); so, objects are defined individually by three things: a state, an identity and behaviors. These might be, for example, the score (technically, the state is defined by the value of an object's fields or variables), the teams playing each other [identity], and the specific actions or behaviors that have occurred during play (sets, spikes, etc.). Oh, and the last important thing: when the game is over, it no longer exists. So too, the object disappears from the world when the user is done. [This is where I have found all other metaphors I've seen to fall short.] Sort of... (someone pointed out to me that you might specifically want to write your program to a database for easy access to "Volleyball's Most Shocking Moments" or something.)