Object-oriented programming, or OOP for those obsessed with acronyms, is a relatively new concept in the world of programming. It can be likened in part to the old GOSUB/RETURN feature of BASIC, and further likened to the concept of procedures and functions in languages.

Basically, with OOP, one can define abstract conceptually-bound objects (or 'classes') in your code, which contain properties that define their behaviour in your program (or many programs). You may then derive further objects (or 'classes') from these classes, which inherit their parent classes' properties and then embellish upon them. Inheritance is the key to OOP - you can define a very abstract class to map out the behaviour of an interface, and then derive more and more concrete classes from this beginning to get their abstract hands progressively dirtier.

The reason for all of this is to promote well-structured programming and (importantly) the re-use of code both in programs and between programs. If all of this seems incomprehensible; don't worry. The only way to really understand OOP is to do it, then fathom it out afterwards.

Basically, object-orientation is based on the properties of tangible things in the real world.

For example, think of a car. Any car. Although all models of cars are different in many ways, they all share many fundamental characteristics - they have wheels, doors, a steering wheel, lights, seats, go 'vroom vroom'. We can group these abstract characteristics and say that should any given object possess these properties in some way or form, it may be loosely labelled 'a car'. So if something's got some wheels, lights, a steering wheel and an engine, it's probably a car.

However, as we know, all cars are different in subtle ways. Some may have three doors, some may have five or more. Some cars may be green, some blue; some may even be more than one colour. So although we have defined an abstract concept of an object that could be classified as 'a car', there are many additional properties which allow us to be more specific about what kind of car it is.

And therein lies the thrust of object-orientation. We can start off with a very basic, abstract entity that loosely defines the most important distinguishing properties of 'a car'; and from that entity, we can add more and more specific features that will eventually allow us to exactly specify what kind of car it is - right down to the number of doors, the colour, the manufacturer, whether or not it's got a CD player. From one basic, abstract object, we can specify a very specific, tangible object, but which still possesses the same properties.

So, how does this relate to programming? Easy.

Above we saw how a very abstract object, or 'class', can be re-used over and over again to specify more specific classes. In programming, this allows us to broadly specify the behaviour and properties of a program function or procedure, and then derive more 'concrete' classes that are more exacting in specifying what the program entity does. So, in a given program, we might need it to have a function that, for example, prints a line of text to a screen. What sort of properties will this function need to mark it as such a function? Well, it'll need to specify what to print, somewhere to print to, and the style in which the text is to be printed. So we create an abstract class of function that defines these properties. But of course, we need to be much more specific than that if we're ever going to get the thing to do anything on screen. So from this abstract class, we derive another instance of the class, which inherits all the properties we've specified and embellishes further upon them. So, knowing that the text to be printed needs to be in some kind of style, we might specify the actual style here - ie bold, italic or so on.

But why bother? Simple. Because we've already specified an abstract class of 'print something somewhere', we can re-use it in the program elsewhere, and we can derive further classes from it that each do different things - print to the screen, print to a printer, print in bold, print in green and so on. The beauty of it is we're re-using the base, abstract class time and time again. We're not rewriting it each time we need to print something in a different manner.

This is a very basic example, but object-orientation, once digested and understood, actually makes programming a lot more intuitive and productive than ever before.