Object Oriented Programming Or Volleyball

As someone who is jumping into the realm of object-oriented programming (OOP), I can tell you that I have been confused by the use of the word

"object;" in this case, mainly because I understood it to be something else entirely based on my experience with JavaScript. [Maybe others are lucky enough to have learned objects right the first time; that is, to understand objects properly when learning JavaScript; I personally had to throw out my notions of objects when I started learning Java, which has been very, very recently].

I've heard people talk a lot about objects lately, both on the evolt discussion list and in the office as we all muck through this stuff. Someone wrote about objects as they relate to JavaScript, while others' explanations touched more on the hard-core programming use of the word. I'd like to start by pointing out that it might be helpful to think of the term "object" as sort of two different things when talking about the two different technologies (JavaScript and Java, for example). See, although they should be, theoretically, the same thing, O'Reilly refers

to objects as "a collection of data" -- which, not to confuse you further, is what objects really are in object-oriented programming -- but then goes on to talk about these objects as almost physical things, like an image, with properties. It seems in JavaScript, that people refer to "objects" as a specific collection of arrays, images, windows, forms, etc; at least, my teachers, colleagues, and (it seems) O'Reilly do.

However, the definition of objects as defined by those involved with object-oriented programming is more accurate, though I don't quite agree with the bicycle or cookie cutter metaphors I've heard and read. See, the beauty of object-oriented programming is that a bunch of different people can use the same class [OOP code] to create a variety of objects at the same time (unlike bikes), but then those objects sort of disappear (unlike cookies) from memory when the work is done. So, I like to think of OOP as sports (which is definitely odd for me,

but, hey whatever works). You have classes -- the code from which an object is created -- that are like individual sports; I like to use 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.)

I hope this helps anyone trying to understand objects, rather than confuses you all. I think because my understanding of objects from JavaScript differs from the idea of objects that I've gotten from Java that I might have muddied things up a bit; let me try to clear that up a little more. You can think of JavaScript objects as arrays and windows and whatever else, but also try to think of them as temporary items created in the browser by a specific code in your document, which doesn't exist for the user or anyone else when no one initiates it.