Unfit For Print

Explaining OOP without Mentioning Classes, Part 1

Posted by Ben Jackson Tue, 22 Nov 2005 14:06:00 GMT

Update: for more fun, read Explaining OOP Without Mentioning Classes, Part 2: The Basics.

In a recent article, David Seah addressed the ridiculously technical Wikipedia entry on Object-Oriented Programming:

In, object-oriented programming, a class consists of a collection of types of encapsulated instance variables and types of methods, possibly with implementation of those types together with a constructor function that can be used to create objects of the class.

It goes downhill from there.

David goes on to write a great example of how to explain things to those new to Flash who are still putting code on buttons:

Classes allow you to group functions and variables together. You do this by using the class statement, which contains all the functions and variables that you want to be related to each other. This can make it a lot easier to organize your program into groups of classes, as opposed to huge lists of functions.

The entire list is great and worth a read. I want to talk about the next step. How do you explain to someone the conceptual shift that comes from organizing functions into groups? The fact is, OOP is much more than just a nice way to avoid global variable conflicts and make your code readable.

When you give something a name, you're increasing your vocabulary. By relating it to something that already has a place in your experience, suddenly you have a number of hooks into your existing vocabulary to describe what it does. Consider the following two specs:

The system will consist of one module that sends messages to one or more other functions which can be added or removed from the recipients list at any time.

The system will use a Publish-Subscribe system, allowing listeners to register and unregister themselves to update after specific events.

With the second one, you immediately have an idea of the main players in the story. You have the Publisher, the Subscriber, the functions addListener() and removeListener(), and the notify() and update(). And, as a bonus, other people can read your code and say "aha!" instead of "wtf?" This cuts down on the number of comments you have to write, all of which (admit it) are more than a month out of date.

I'll end this with the obligatory caveat that beginners are prone to dive head-first into the kiddie pool if they don't remember to exercise restraint with their newfound powers of abstraction. Just because you can doesn't mean you should. If you ever write a class with nothing but one instance variable, you have crossed the line. Step back and look around.

Stay tuned for the next installment.