Last week, my wife decided to start learning PHP.  And no, she’s not just trying to humor me–pssh, like she’d do that.  She’s burning to code some roleplay generators.  It’s a bit of a blast, sitting and coding side-by-side.  (And not just because I get to work on Escher without feeling guilty!) She’s doing a great job, picking it up like lint, and it’s fun to see her sense of accomplishment.  I miss that sort of instant gratification that came in old days, before PHP became a paying gig and I started counting lines of code by the tens of thousands.  Say what you will about rapid development frameworks…  Nothing beats the efficiency of a single-file script running linear or functional code and inline HTML.

For a small project, at least.  Since she’s been doing so incredibly well, I thought I’d try and show her a thing or two about PHP classes so she can get her code more compartmentalized and portable.  After all, in the past week, this endeavor has grown from a simple desire for a few one-off scripts to the possibility to create our own RPG system and an accompanying website.  So we might as well start thinking ahead, and no better way than OOP, right?

Oh, wait…

OOPs.  (Yeah, I went there.)

In my arrogance, I’d forgotten something significant about object-oriented programming.  Nevermind that OOP is a godsend, that for large projects it makes things exponentially more manageable, or that we proabably all use a lot of OOP whether we know it or not, thanks to all the libraries and database wrappers and even a lot of built-in PHP5 functionality.  There’s something off-putting about OOP when you aren’t already coding it.  It seems unnecessarily complicated, and there are really no great & simple ways to describe its advantages.

Heck…  I hated OOP.  With a passion. I avoided it for years, and managed to build a pretty respectable website without it.  OOP was just a cult, and they were never gonna suck me in.  Well, now look at me.  I’ve joined the cult, I’m sporting the weird haircut, and I’m sippin’ the koolaid daily.

So, how can I explain OOP to my wife in a way that makes sense?  (Not makes-sense makes-sense, but makes-sense why-should-she-bother?)  The real-world analogies never worked for me.  (”You’ve got a building object, and a door object, and maybe we want to extend a door object to have a lock…  yadda yadda…”)  Even still, I find that those analogies actually screw up my perspective on a project, I think because physical hierarchy and structure is just plain different from programmatic hierarchy and structure.

I think, perhaps, the best analogy for OOP programming might actually be non-OOP programming.  Functional programming, at least.  The automation and portability provided by writing our own functions is not difficult to see first-hand.  OOP actually behaves in a very similar manner, and takes our portability to the next level.

Read the rest of this entry »