Rabbit Creative

I’m betting ninety-five-plus percent of all, “object-oriented” programmers are posers. I bet you’re one, too. You think you’re a bad ass, swinging your Java || C++ || Ruby-emblazoned sword around like a furious ninja out to get revenge on the nerd across the street. Unfortunately, all your swinging is futile, as your code is probably anything but object-oriented. Don’t worry though, it’s (probably) not your fault. You’ve likely been taught that object-oriented programming is simply “programming with objects,” and an object is nothing more than a collection of variables and methods. But objects are those not, and object-oriented programming is more than simply “programming with objects.” What object-oriented programming really means.

Most programmers using an object-oriented language are not programming in an object-oriented manner. “Object-oriented,” both as a phrase and idea, transcends language and technology; it is a mode of thought. It is quite possible to program with objects using a language that does not support object-oriented expressions. Similarly, programming in Java, C++, or even Ruby, does not mean you are programming in an object-oriented fashion.

Before we go any further, let’s both agree to stop saying, “object-oriented.” Instead, we’re going to say, “object thinking.” It’s more appropriate, and, as I said earlier, the concept of objects is a mode of thought, not a language or technology. So what is object thinking?

Object thinking means, quite literally, thinking like an object. “Thinking like an object” involves temporarily suspending your sense of self and assuming the identity of the object you’re interesting in modeling. This includes what capabilities you have, your responsibilities and who you must communicate with in order to perform fulfill those responsibilities.

In programming, all objects are behavioral objects. That is, they behave in a manner consistent with the domain in which they exist. Imagine a POS machine. Sure, it’s inanimate, doesn’t eat, breathe or sleep, but it still exhibits behavior. We know this because we can interact with it, and when we do, we experience the effects of that object’s behavior. We can push buttons on the POS machine, swipe a credit card and even curse towards the machine when it “misbehaves.”

If this still sounds odd to you, turn your thoughts inward for a moment. You’re standing in the desert, staring down at a large rock. See it? Good. Now, command the rock to move. “I command you to move, rock!” … Feeling silly yet? Unless you’re a Jedi, the rock didn’t move. But then again, did you really expect it to move? Of course not. It’s a rock, you don’t have any expectations that this or any other rock will obey verbal commands.

Let’s pause briefly. We didn’t expect the rock to move. And sure enough, it didn’t. Therefore, we’re accurate in saying the rock behaved accordingly. All things, even those seemingly unlikely candidates, are behavioral objects. And we, being observant, objective humans, have expectations, assumptions really, about how the objects in our world act and how we can interact with them.

How does this tie into programming? Let’s play a game of Black Jack…