Object-Oriented Computing - What's the Big Deal?

So what exactly is O-O?

Object-Oriented Computing is a different way of looking at the world.

Let's start with an example.

Suppose you're at the dinner table, you would like some salt, and the salt shaker is inconveniently located at the other end of the table.
You might say to your friend "Please pass me the salt", and she would do so (assuming that she is your friend, and also one who doesn't feel it her moral duty to deny your request in the belief that she is prolonging your life by reducing your sodium intake. But I digress).
On the other hand, instead of saying just "Please pass me the salt", you could try "Please remove your right hand from your wine glass, move it to the left until it contacts the salt shaker, grasp it, lift it from the table, move it in a natural arc in my direction, stop when it contacts my hand, wait until my hand has closed around it, and then release it." This would probably work as well, though it might also result in a quiet phone call from your friend to the local mental asylum.

Think about the second option. Sounds pretty silly, doesn't it? Yet, in classrooms, universities, homes and companies throughout the world, thousands of programmers have been doing the software equivalent of exactly that for decades.

This is the difference between procedural (old) and object-oriented (new) computing. The object-oriented way is to say "Pass the salt", and leaves it up to the object (no offence to your friend here) to carry out the request any way it chooses. The procedural way is to specify each and every step of getting that shaker of salt into your hot little hands.

Is that all there is to O-O?

Well, not quite, but that is the single most important principle of object-oriented computing. I kid you not! Everything that follows stems from this idea:

Objects ("salt-passers") are responsible for their own actions in responding to requests from clients ("salt-wanters").

Now maybe you're one of those people who has little time to sit at a dinner table, because you're eating all your meals in front of a computer screen, trying in vain to meet yet another unreasonable deadline. Well, don't despair, because my next example is just for you.

Let's see how this principle (objects are responsible for their own actions) works in a computing environment.

Suppose you've writing a software system for a bank, and you need to know the balance of a particular customer's account.
If you're doing things the procedural way, you might do something like this: Starting with the balance at the start of the month, read each transaction in turn, and add or subtract its value as appropriate.
On the other hand, if you're doing things the object-oriented way, there will be an object for the customer's account, and you simply ask it to return you the balance. Simple, no?

Of course, the object-oriented way is not as simple as I've made it out to be. Obviously, behind the scenes, the object representing the customer's account must calculate the balance using something like that used in the procedural way. But that's precisely the point: this is behind the scenes. Remember the single most important principle of object-oriented computing: Objects are responsible for their own actions.

"Enough, already - I get your point!" (I hear you cry).

OK, OK, let's move on.

There are two key concepts in object-oriented computing: encapsulation and inheritance. Let's look at each of these in turn.

Encapsulation

We've already seen encapsulation, although I didn't call it that at the time. It's the principle I've been repeating at every opportunity: Objects are responsible for their own actions. Let's expand on this, and look at some of its consequences.

Model Real-World Objects

First, at the risk of boring you (Oh, it's too late for that, is it?), I'll say again that this is the key principle which distinguishes procedural from O-O programming. Procedural programming is based on performing actions on data . O-O programming is based on the data (objects) performing actions on themselves.

One immediate consequence of this (the O-O method) is that we're describing objects in the real world more closely. In the same way that you don't have to give detailed instructions to a friend to pass you the salt (because she knows how to do it), you don't have to tell an object how to perform its request (because it knows how to do it).

Now, you may say that older methods (such as structured analysis) also model the real world, and you'd be right. The difference is that these methods focus on data flow, while object-oriented techniques focus on objects. The advantage of modelling objects in the real world is that you reduce the amount of work you have to do when your requirements change. Why? Because, as a rule, objects in the real world don't change (and even when they do, they don't change much - see Inheritance below), but the way in which you use them and the way in which they interact with each other (i.e. the data flow) does change. Your obliging friend who passes you the salt doesn't know - and doesn't need to know - if you want it to sprinkle over your chicken casserole, throw over your left shoulder, build a salt castle on the tablecloth, or scatter to the four winds. She knows how to pass you the salt, regardless of what you plan to do with it.

Isolate Knowledge

Another advantage of encapsulation is that the knowledge of how a service is performed by an object is kept with the object itself, and doesn't clutter up the code of every other object which uses it. Your obliging friend picks up the salt and passes it to you. Another friend might have chosen to slide it across the table. Another might have picked it up, stood up, walked around the table and handed it to you. Yet another might have checked the salt shaker, found it empty, stood up, walked to the cupboard, refilled the shaker, and then passed it to you. The point is that if your objective was to get the salt from your friend, you don't care exactly how your friend gets it for you.

Protect System from Change

This separation of what from how is important for another reason - it makes the system easier to change later. Go back to my original example of passing the salt and re-read the second option (the option where you tell your friend exactly how to pass the salt). Look how much detailed knowledge about salt- passing you're using to make your request. You're not only making a request, you're also insisting that it be carried out in a specific way. If your friend later comes up with a different way of passing the salt (e.g. balancing it on two toothpicks), then you (and everybody else who has insisted on her doing things the old way) will have to change the way you make your request. If, on the other hand, you leave it up to her to decide how to pass the salt, if she comes up with a new, more effective, more efficient, faster, cheaper, funnier, or more creative method, you still get your salt.

I can't emphasise the importance of this enough. Customer requirements change all the time, and your software needs to change with them. If you can write software which is easier to change, then you can keep your head when all about are losing theirs, and yours is the world and everything that's in it.

Use Behaviour from Other Objects

Finally, one more advantage of encapsulation is something called polymorphism. Simply put, this means that more than one kind of object can fulfill a request. The requestor doesn't know and doesn't care which kind of object actually fulfilled a particular request.

Again, an example will help. When you say "Pass the salt", your friend gives it to you. Or does she? It could be that somebody from the other side of the table reaches over and hands it to you. Or perhaps your well-trained labrador retriever jumps up, grabs the salt shaker in its mouth, and brings it to you. Or maybe you have invited the town robot over to dinner that night, and it reaches over with its metallic arm to pass you the salt. Does it matter? No. More than one "object" out there knows how to pass the salt, and as far as you're concerned, it doesn't matter which one actually carries out your request. The end result is the same - a salt shaker in your hand (or, if the robot uses a Pentium chip, at least somewhere in the vicinity of your hand). That's polymorphism for you.

Inheritance

In the real world, we often classify things by how similar they are to each other. Dogs, cats, lions and tigers are all "mammals". Everest, Mont Blanc and Vesuvius are all "mountains". VW Beetles, Rolls Royces and Cadillacs are all "cars".

By classifying kinds of objects by their similarities, we can talk about their common properties. And we make use of these common properties in communication.

Let's take mountains, for example.

If you and I both understand the concept of "a mountain" even vaguely as a pretty big pile of earth with a pointy bit at the top, then we can communicate pretty effectively about mountains (How high is the mountain? Where is it? What's it made of?).
So we understand what all mountains have in common, but of course mountains like Everest and Vesuvius are also different from each other (just ask the people of Pompeii). So we might now want to talk about a volcanic mountain. So we simply define what makes it so special: Hot red liquid can flow out of the pointy bit.
Here's the crucial point: To understand about volcanic mountains, we only need to add to our existing knowledge of mountains. Because we knew all the common properties of mountains already, we didn't need to learn them all over again when we learned about volcanic mountains.
We can say that "volcanic mountains" inherit all the properties of "mountains", and then adds its own properties.

That's inheritance for you.

Let's look at a software example.

Suppose you've been asked to write a software system to keep track of all a bank's customers. You've been converted to O-O (perhaps by reading a well-written and convincing article like this one), and you're in the process of designing a "Bank Customer" object.
Suddenly you remember that in your previous system, you had kept track of customers for a small bookshop. You already have a "Customer" object, with properties like: name, postal address, phone number, fax number, and so on.
All the properties of this Customer object apply to the bank's customers as well, but you want to add a few more - say, credit rating and security password. In building your Bank Customer object, you simply re-use all of the Customer object, and then add the new properties.
In O-O jargon, Bank Customer inherits from Customer.

Inheritance is such a powerful technique because it allows us to capture the similarities and the differences between classes of objects. By looking at the similarities, we can extract the common behaviour first, and model this behaviour. By looking at the differences, we get into the nitty-gritty of the details. This gives us a much more orderly way to describe our objects, as opposed to simply lumping all the properties together.

A significant advantage of inheritance is that it can increase reusability greatly. Look at the software example above, and see how we were able to re-use the Customer object from the bookshop in creating the Bank Customer object for the bank.

But beware! The degree of reusability you get depends on how well you model the objects in the first place. If the original Customer object had information about, say, reading preferences, favourite authors and list of books purchased, then it's not so easy to use this Customer model for the bank because some of these properties are just not applicable. The Customer object isn't general-purpose enough.

One of the hardest things in O-O analysis is to decide how general-purpose you want to make your model.

There are no hard-and-fast rules. One of the greatest skills is to decide how to balance short-term project needs with generalisations for the future.