Eggheads: helping us to visualise objects and classes

Ada the Egghead: a purple face with pinky purple hair
Ada the Egghead
Image by Daniel Gill for CS4FN

Past CS4FN articles have explored object-oriented programming through self-aware pizza and Strictly Come Dancing judges. But, if you’re one of those people who like to learn visually, it can be challenging to imagine what an object or class looks like. This article will hopefully help you to both think more about what makes this paradigm so useful as well as to give you a way to visualise objects.

To begin this adventure, I’d like to introduce Ada. Ada is an example of the newly discovered species egghead. Every egghead has very distinctive hair and eye colours. For example, Ada’s hair is a delightfully bright pink, and their eyes, a deep red. Despite their appearance, the egghead has a vicious roar intended to ward off predators, or indeed poachers.

Classes

As computer scientists, we might want to represent different eggheads in a program, but we don’t really want to store information about the eggheads with a written description or an image, because this would be harder than need-be for a computer to ‘understand’ (or rather to process as they don’t understand as such). Instead, we can store lots of individual features together, so that the computer can find out exactly what it needs from each egghead.

Egghead
Name
Hair
Eyes

Roar button
Egghead class. Image by Daniel Gill for CS4FN

One way to achieve this is by using a class. A class is a template which contains spaces for us to fill in details for the thing we want to represent. For the egghead, we might want to store data about their name, hair colour, and eye colour – then we can fill in the template for each of the eggheads we find. These individual features are often called attributes. In a program, these attributes would be represented with variables: a place where a value, a piece of data, is stored. We can visualise a class therefore as a box with gaps to fill in for the attributes like the one on the left.

From this image, you will see alongside the attributes, we also have an image of a button for roaring. As well as storing attributes, we also define behaviours. These are actions that we can perform on the thing being represented. We visualise any behaviour as such a button. For this example, we could imagine that pressing this button might provoke the egghead causing them to roar. In programming, a behaviour is represented by a procedure, some pre-defined code that when executed makes something happen. A button that causes something to happen is a simple way to visualise such procedures.

A key point to realise is that this class is simply a template – it isn’t storing any information, nor will the roar button work. We have no actual eggheads yet… That is where objects come in.

Objects

You may have noticed that I have been using the word thing to represent the actual thing (here eggheads) that we are representing with the class. This is to avoid using the word object, which has its own special meaning, in, you guessed it, object-oriented programming. If we want to actually use our class, we need to make an instance. That just means filling in the relevant details about the specific egghead we want to store. This instance is called an object.

Let’s imagine we want to store a representation of Ada in our program. We would take an instance of the Egghead class and fill in their details. The resulting object would represent Ada, whereas the class we started with represents all and any egghead that might ever exist. Below, you can see the objects for Ada and some of Ada’s friends; Alan and Edsger. We still visualise objects as boxes, just like classes, except now the gaps are all filled in.

Eggheads with values for the fields eg
Ada
Pink
Red
Objects representing Ada, Alan and Edsger. Image by Daniel Gill for CS4FN

We (or a computer) could even take the given features of Alan and Edsger and generate an image of what they might look like. We have everything we need here to create something that looks and behaves like an egghead. This method of storing data means that a program can take whatever information it might want directly from the object. Likewise, it can do the equivalent of pressing the roar button and make each individual egghead roar.

Hiding the Details

Egghead with blue changed to orange
Trying to change Alan’s eye colour. Image by Daniel Gill for CS4FN

One thing we should consider while making the class is the integrity of the data. In its current form, any other part of our program, or another program using our class, can directly edit the attributes stored. Another part of the program (perhaps representing a virtual world for a virtual egghead to live in) might accidentally change the eye colour attribute for Alan, for example. This wouldn’t change Alan’s actual eye colour (which couldn’t happen anyway!), so our data would then be wrong. We can’t have that!

We can fix this by hiding the eye colour from the rest of the program, so it is stored within the object, but not accessible outside of it. But we still need a way for the program to read it: for this we use a button in our picture of the Egghead class. The existence of the eye colour attribute can then only be seen by other parts of the program by a procedure that gets the eye colour. No similar procedure is given for changing the eye colour, so there is no way to do it by mistake. Let’s build this new version of our class.

Sequence as values change
(a) Our new class, (b) An object representing Edsger, with eye colour hidden, (c) Pressing GetEyes gives us the eye colour. Image by Daniel Gill for CS4FN

This concept of hiding details is sometimes called encapsulation or information hiding, but computer scientists disagree about what these terms refer to exactly. Encapsulation is broader in its meanings, whereas information hiding is closer to what we are trying to do here. This video by ArjanCodes (see below) explains this distinction further.

We could change our class to include this concept for the name and hair colour, too. Whilst it is entirely possible for these attributes to change, it turns out that it is a good idea to hide them too: so hide name and use SetName and GetName buttons. That allows us to control the type of data we have going into that attribute (for example, checking the given name isn’t a number, which as all egghead names are made of letters would be a mistake).

Where next?

Now we have a class that represents all eggheads, we can store the details of any new egghead efficiently and safely. Hold on… some last-minute breaking news: scientists have found a new sub-species of egghead they are calling a rainbow egghead. All rainbow eggheads have rainbow hair, and a unique roar. Next time, we’ll use the concept of inheritance to give a more efficient way to write programs that store information about eggheads.

Daniel Gill, Queen Mary University of London

More on …

Watch…


Subscribe to be notified whenever we publish a new post to the CS4FN blog.


This blog is funded by EPSRC on research agreement EP/W033615/1.

QMUL CS4FN EPSRC logos

Object-oriented pizza at the end of the universe

Object-oriented programming is a popular kind of programming. To understand what it is all about it can help to think about cooking a meal (Hitchhiker’s Guide to the Galaxy style) where the meal cooks itself.

People talk about programs being like recipes to follow. This can help because both programs and recipes are sets of instructions. If you follow the instructions precisely in the right order, it should lead to the intended result (without you needing any thought of how to do it yourself).

That is only one way of thinking about what a program is, though. The recipe metaphor corresponds to a style of programming called procedural programming. Another completely different way of thinking about programs (a different paradigm) is object-oriented programming. So what is that about if not recipes?

In object-oriented programming, programmers think of a program, not as a series of recipes (so not sets instructions to be followed that do distinct tasks) but as a series of objects that send messages to each other to get things done. Different objects also have different behaviours – different actions they can perform. What do we mean by that? That is where The Hitchhiker’s Guide to the Galaxy may help.

In the book “The Restaurant at the End of the Universe”, by Douglas Adam, part of the Hitchhiker’s Guide to the Galaxy series, genetically modified animals are bred to delight in being your meal. They take great personal pride in being perfectly fattened and might suggest their leg as being particularly tasty, for example.

We can take this idea a little further. Imagine a genetically engineered future in which animals and vegetables are bred to have such intelligence (if you can call it that) and are able to cook themselves. Each duck can roast itself to death or alternatively fry itself perfectly. Now, when a request comes in for duck and mushroom pizza, messages go to the mushrooms, the ducks, etc and they get to work preparing themselves as requested by the pizza base, who on creation and addition of the toppings, promptly bakes itself in a hot oven as requested. This is roughly how an object-oriented programmer sees a program. It is just a collection of objects come to life. Each different kind of object is programmed with instructions about all the operations that it can perform on itself (its behaviours). If such an operation is required, a request goes to the object itself to do it.

Compare these genetically modified beings to a program, which could be to control a factory making food, say. In the procedural programming version we write a program (or recipe) for duck and mushroom pizza, that set out the sequence of instructions to follow. The computer, acting as a chef, works down the instructions in turn. The programmer splits the instructions into separate sets to do different tasks: for making pizza dough, adding all the toppings, and so on. Specific instructions say when the computer chef should start following new instructions and return to previous tasks to continue with old ones.

Now, following the genetically-modified food idea instead, the program is thought of as separate objects, one for the pizza base, one for the duck one for each mushroom, so the programmer has to think in terms of what objects exist and what their properties and behaviours are. She writes instructions (the program) to give each group of objects their specific behaviours (so a duck has instructions for how to roast itself, instructions for how to tear itself into pieces, for how to add its pieces on to the pizza base; a mushroom has instructions for how to wash itself, slice itself, and so on). Parts of those behaviours the programmer programs are instructions to send messages to other objects to get things done: the pizza base object, tells the mushroom objects and duck object to get their act together and prepare themselves and jump on top, for example.

This is a completely different way to think of a program based on a completely different way of decomposing it. Instead of breaking the task into subtasks of things to do, you break it into objects, separate entities that send messages to each other to get things done. Which is best depends on what the program does, but for many kinds of tasks the object-oriented approach is a much more natural way to think about the problem and so write the program.

So ducks that cook themselves may never happen in the real universe (I hope), but they could exist in the programs of future kitchens run by computers if the programmers use object-oriented programming.

Paul Curzon, Queen Mary University of London

This article was based on a section from Computing Without Computers, a free book by Paul to help struggling students understand programming concepts.

More on …

Related Magazines …


EPSRC supports this blog through research grant EP/W033615/1.