Object Oriented Programming 2

Imagine creating a blueprint for an intelligent robot. The robot’s purpose is very simple: to open the curtains in the morning, and to close them at night. You call them CurtainBots, build three of them, and install them in your home. Great…

Now, if you consider the blueprint as a class, then what you have done is to create three objects of the class CurtainBot, and you might call them CurtainBot1, CurtainBot2, and CurtainBot3. These objects have a particular set of features, and also have tasks defined which depend on certain events: dawn and dusk. In other words, they’re event driven.

It’s a little more complex than that, of course. You have three of the robots, and you may have a dozen or more windows with curtains. So, which robot does which window? Has this been pre-decided in the code? As an approach this is poor, as it would be better to have the robots know what a window is, to search for them, and to deal appropriately with any it encounters. It would be better still if the robots could cooperate with each other, so that they can between them decide that their task is completed, rather than all three having to circuit the entire house.

This, it turns out, is the basis of object oriented thinking: to create classes of objects that are similar and well defined in terms of their features and tasks. These objects need to communicate with each other and to cooperate in order to achieve tasks efficiently.

Maybe not so simple, but powerful. In fact so powerful that object oriented (OO) capabilities are now included in many modern programming languages. This introduction will look at the class, the fundamental concept in all languages that use OO.

The Class

In object oriented programming (OOP), a class is short for classification. According to dictionary.com, classification is the act, process, or result of classifying. It’s the basic process of grouping similar objects, and this is a useful concept in programming, because it’s what we do in our everyday life. It’s how we learn to understand the world, and develop thought, language and so on.

The OOP class, then, is a formal programming construction that mirrors this natural process of grouping similar things.

Abstract Data

Often a computer program’s job is to try and emulate in some way a real world situation, but it clearly can’t handle every single detail. Thankfully, it doesn’t need to; for instance, you really don’t need a person’s hair colour to get their bank balance.

To a computer program this is important. Efficient software requires everything superfluous to be filtered out while keeping the quality data that’s needed – in other words, to abstract the necessary data, and create variables for only those data.

As an example, take horses. With horses, you can make certain assumptions about them, because without certain basic things it wouldn’t be a horse. For instance, when someone is talking about a horse, you don’t need to be told that it has four legs, two eyes and it says neigh. They just say horse, and you know those things. But, you might want to know its breed, hands high and colouring, because these are the things that vary from horse to horse.

We know that if we were constructing a class for horses, we’d only concentrate on the information that’s relevant. In other words, we’d abstract what we needed, and the rest would be quietly ignored. So in our class, we’d likely have variables for breed, hands high, and colouring.

And with all this abstracting, guess what? Yup, a class is referred to as an abstract data type, or ADT.

But, we can’t stop just there…


Many languages provide abstract data types, like C’s structure. But this would be where a discussion of the C structure stops, because the structure is only able to hold data. The class, however, takes things a step further, and this is really where object-orientation begins to kick in.

Continuing with the horse analogy, if you imagine not only all the things that you would measure to define a horse, but also all the things that you would do with a horse, doesn’t it makes sense to describe the tasks together with the data? After all, riding, grooming and carting are as much a part of your general horsing as are its height and colour. So, if you’re going to have to write these methods anyway, why not keep them together with the horsey data?

In the OO class, this is exactly what happens, and it is the basic form of encapsulation which we’ll look at next