Saturday, July 10, 2010

Objective Objectification of Objects

Why is it that nobody seems to be able to describe or explain "Object Oriented Programming" worth a shit?  I'm serious.

During seven years of college (ok, 2 years for my AAS, and 5 for my BS, I can add, and my loans sure add up, but nevermind) all of the courses and textbooks and lectures tried to clear this up, over and over again.  None of them hit the nail on the head.  None.  Nothing I've read since then either has done much to really clear this up or serve as the official definition for all levels of understanding and background.

Here's where they fail:  They attempt to describe the concept to what they think is a target audience of programmers. A very bad choice.

I get it, as do most programmers, but then again: we're programmers.  If you can't state the definition to someone who has NEVER programmed, what OOP means in ONE sentence, and they nod in complete and total understanding, then this is still unfinished business.

Anytime you want to explain something "clearly", think of your target audience as a room full of senior citizens who just consumed their daily dose of sedatives and laxatives and are lounging around the TV room waiting for their worthless kids to never visit (unless they need to discuss legal or financial matters, of course).  These are the people you need to inform and impress.  Pay attention, this will show up again in your life.  Imagine the following conversation in a room of these people. One of them asks "what is 'object oriented programming' Jimmy?" (you're Jimmy of course)...

You respond: "Well George, it's where you define things in 'classes' and then 'instantiate'..."  BANG!  conversation is over.  They already drifted off.  Either towards the Wheel of Fortunate chatter on TV across the room, or just went comatose on you.  You can snap your fingers, poke or pat their arm, or even straddle their wheelchair and grab their head with both hands and shake them like a paint can machine.  It's not going to help.  See that picture above?  That's your audience.  Start practicing.

This article on "Object-Oriented PHP for Beginners" written by Jason Lengstorf, on NetTuts (link: http://net.tutsplus.com/tutorials/php/object-oriented-php-for-beginners/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+nettuts+%28NETTUTS%29&utm_content=FaceBook) is very good, but it also joins the long list of nails whose heads have been left unscathed by the hammer of clarity.  (Damn! That was a clever line.  Hold on... I have to basque in the glory of having thought of something cool like this....I should copyright it.  Ok, I'm back.)
Near the beginning of this article, the author provides a quote box with the following OOP definition: "Object-oriented programming is a style of coding that allows developers to group similar tasks into classes."

This is 2010.  Holy shit!  WTF is that?!  If a "programmer" doesn't know the definition, or at least a rough idea, of what OOP is, they are also likely new to programming in general.  If you're talking to a noob, that statement doesn't cut it.  This is exactly what I'm talking about.  I am not picking on Jason here, he really is not to blame, and his article is very good indeed.  The institutions of programming and training are to blame.  Authors and instructors are to blame.

Programmers have an extremely tough time correlating tangible concepts to intangible concepts.  At least those that are classically trained.  Those that are self-taught often possess a good grasp of the conceptual relationships, but struggle to verbalize it to novices.  It's one of those "I can drive there, but don't ask me for directions" kind of things.  Let's face it, a lot of cooks can make awesome dishes but are incapable to sharing the details on how they're made.  "A little of this" and "a little of that" don't really mean much to someone new to cooking.  We need "a quarter teaspoon of this" and "2 cups of that".

So, you ask, "Why don't YOU attempt to correct this, Mr. Know-it-all?  Hmmmm!?"
I didn't say I have the answers.  I just said that none of the other answers are worth a crap.

I did however attempt to employ my 11 year old son as a test subject (he calls it being a victim, but whatever).  He was poking around learning Javascript because his friends told him it was the key to hacking his favorite online games.  So he got a book at the library and started tinkering.  I have no idea where this came from, but I was impressed of course.  He got to the chapter on "OOP" and ran into the expected confusing blob of words that makes no sense to anyone except seasoned programmers.

I'll spare you the details, but essentially I used the common 'People' class example, with one of his friends 'Mark' as the object instance of the 'People' class.  That was so-so.  Then I used the 'vehicle' class example, with 'automobile' sub-class, 'chevy' sub-class, and my truck as the object (with a specific VIN to identify it from other trucks).  He quickly reminded me that I sold the truck a year ago, so I had to back up and use the Subaru example.

He got the idea but it was almost as awkward and painful to get through as describing the birds and bees to him.  Come to think of it, birds and bees could be an example for OOP, but only when they hit their teens.  I'm sure he'd quickly raise his hand and ask how birds and bees are related at all, which is a good point.  Someone should have used "bees and flowers" instead.  Oh well.
The point here is that OOP is tough to explain, clearly, in purely intangible terms.  It always leads to using tangible metaphors and analogies, and then trying to stitch that together with a painfully clumsy jump to the intangible side, and that's like watching Gilbert Gottfried running a 100 meter hurdle race.

Like I said: I don't have a good answer.  I'm just begging someone with literary skills, a decent grasp of OOP and an ability to think tangibly and intangibly, to take a better stab at this than I (or anyone else thus far) has been able to accomplish. Please.  For the good of all nerdkind.

No comments: