ÐÓ°ÉÔ­´´

OOP sounds like just another acronym of the computing world, and there are already far too many of those. The difference is that OOP might save your life one day although, as with many technological revolutions, you are unlikely to be aware of it.

OOP stands for Object Oriented Programming and is a radically different way of writing computer programs. OOP is not in itself a computer language, it is a mixture of several methodologies and ideas about how programming can be performed efficiently. Some languages, such as Smalltalk and Eiffel, have been written specifically to make the best use of its features; but OOP can also be ‘bolted-on’ to existing languages, such as C and Pascal. One of its most important attractions is that it should reduce the number of mistakes that programmers make.

As our lives are increasingly controlled by computer programs – everything from credit transfers to aircraft landing systems – it becomes increasingly important to eliminate as many mistakes as possible. An error in a program that controls an aircraft’s landing system could kill 400 people in one go.

The chances of an error occurring in a computer program increase with the size of the program, which is often measured in terms of the number of lines it contains. The average programmer can write tiny programs, that is between 10 to 20 lines long, without making any mistakes. Indeed, it is possible to prove mathematically that such programs are correct. But programs of this length are trivial, while those to which we entrust our money and our lives stretch for hundreds of thousands of lines, way beyond the capabilities of man, woman or computer to guarantee as error-free. As a result, programmers have turned to methodologies, such as OOP, to reduce the risks of making mistakes.

OOP is only one way of attempting to reduce bugs. Another is to design an entire language in which it is difficult to write code containing errors. One such is Ada, the language developed in response to a study conducted by the US Department of Defense. But Ada suffers from two problems, design and size. It was designed by a committee and, as a result, represents a mish-mash of opinions and compromises. On the matter of size, the respected designer of Pascal, Niklaus Wirth, feels that a reasonable compiler for a language – the compiler is a program that converts the language into machine code – is about five thousand lines of code. Ada compilers are typically several hundred thousand lines long. So, although OOP is not the only solution, it seems the most realistic one at the moment.

The first stage of writing a program is usually to ask the users what they want from it. In describing their requirements, non-programmers almost always talk in terms of objects. The problem with traditional programming techniques is that in order to write a program the programmer must first convert these object-oriented descriptions of the program into very abstract numerical representations. Errors occur both in the conversion and in the subsequent manipulation of these sets of numbers.

The OOP philosophy, if one can call it that, is based around the premise that programmers are relatively normal people and they too are much better at thinking about objects than numbers. OOP effectively allows the programmer to construct software models of objects that can then be manipulated during programming in a manner more closely resembling the handling of real objects. In defining objects, it allows the programmer to write code more intuitively.

Suppose we consider a piece of software designed to represent aircraft instruments. Modern airliners use a mix of traditional instruments and computer-generated ones that appear on a VDU screen. The advantage of using computer-generated ones is that the same screen can, at the flick of a switch, display a huge number of different instruments, one after the other or in small groups, thus reducing the clutter in the cockpit.

When asked to describe how the system should operate, pilots will say: ‘When landing, I want to be able to press a button and have six instruments appear. These should be the altimeter, airspeed indicator . . . ‘ and so on. They are describing objects they want to appear on the screen. If pressed for information about these objects, they can probably describe what they want in detail. ‘The altimeter should have green figures and hands, and a black face. It should be calibrated in feet, have three hands . . . ‘ and so on.

In traditional programming, turning this description into lines of a program involves representing the altimeter to the computer as a series of numbers. These numbers indicate the colour of the instrument’s figures and hands, its face colour, size, scale, the aircraft’s current height and so on. Such a numerical description is known as a ‘data structure’. Though the numbers are essentially arbitrary, there happens to be an unofficial standard for numbering colours in a computer program; for instance, black is 0 and green is 2. For the altimeter, the programmer might write ‘Colour = 2’; ‘FaceColour = 0’; ‘Size = 42’; ‘FullScaleDeflection = 100 000’; ‘CurrentHeight = 0’; ‘NumberOfHands = 3’.

In addition, the programmer must devise sections of the program, for instance, to change the reading on the altimeter and move its position on the VDU screen. These pieces of code, which perform actions on the data structures, can be as abstract as the data structures themselves.

The pilots might then give an instruction: ‘When the height falls to less than 500 feet, we want the directional indicator to go blank, and the altimeter to double in size.’ The programmer has to turn this relatively clear description about objects into a series of abstract manipulations. These might involve turning the number in ‘FaceColour’ for the directional indicator to that indicating white (15), looking up the value for the ‘Size’ of the altimeter (42) and doubling it (but remembering to ensure that it does not exceed some other arbitrary number in case it becomes larger than the screen) . . . and so on.

The original instruction, which was concerned with objects, is still clear in the programmer’s mind, but the execution is so mixed up with abstract data structures that it is easy to put a number in the wrong place.

OOP simply extends these traditional programming techniques. An object is once more described in terms of numbers that are stored as a data structure. Then, in a departure from traditional techniques, OOP defines ‘methods’ that determine how that data structure may be manipulated. For the altimeter, these methods would enable the instrument to be resized, its colour to be changed, or the reading (height) that it displays to be updated. Every action the program had to perform on that object would be described as a method.

Thus, in OOP, the data structure and the code that manipulates it are immutably tied together, a feature known as ‘encapsulation’. Programmers cannot apply a method written for one data structure to another one accidently. This should make it impossible to update the altimeter and discover, instead, that the engines have gone into reverse thrust, which could happen with conventional programming. Furthermore, the code for a data structure and its methods can be written and rigorously tested in isolation to reduce the chances of errors escaping detection.

Another important benefit of OOP is the concept of ‘class’. In defining the data structure and its associated methods, the programmer is in fact defining a class of objects. Without having to write any more code, the program can have many different objects of that class. Suppose that the aircraft has 50 electrical circuits, each of which needs to be monitored by a separate voltmeter. The programmer would need to define a voltmeter only once in terms of data structure and methods, thereafter as many different voltmeters as required, all showing different voltages, could be shown on the screen at the same time.

Creating these classes, methods and data structures to define objects and the way they should work requires pre-planning and an initial investment of time. But once this has been done, the programmer has only to match methods to data structures to manipulate any object from an entire class of objects, instead of writing a series of different programs to control the different jobs of every single object. In a study published in 1991, Arinc, an American company specialising in ground-to-air communication systems for both civil and military use, reported that a program expected to take 32 months to write in a conventional language was completed in 9 months using OOP.

Another advantage of OOP is that it makes it easier for a new programmer to join a team already working on a long and complex program. As a class is addressed only via its methods, a programmer taking over a section of the program needs only the names of the classes and a list of their associated methods to continue a job started by someone else – there is no need to learn the complexities of the internal data structures of the classes. A subsidiary benefit is that if the data structure of an object is found to be unsuitable at a late stage in the writing of the program, it can be changed without altering its associated methods at all. Other team members need not even be informed of the change as they will not have to alter anything they have written.

There is a drawback in this isolation of a class, however. If an error remains undiscovered in a class, then all data structures derived from that class will contain the error. But proponents of OOP stress how much more unlikely this is than with a traditional language.

For the altimeter, the programmer might create methods called ‘ChangeFaceColour’, ‘ReSize’, ‘UpdateReading’ and so on. These can then be used to perform operations on the instrument. The syntax will vary, depending upon the lan-guage, but would be something like, ‘Altimeter. ChangeFaceColour(Red)’, or ‘Altimeter. ReSize(2.0)’.

Once the methods have been written, the programmer uses them like verbs to perform actions on the objects. This has been referred to as ‘programming in the active voice’. One of its greatest attractions is that it makes mistakes less likely. A tired programmer, working crudely in a traditional lan-guage might write, ‘Ae(5) = 4’, in mistake for ‘Al(5) = 4’. Instead of changing the colour of the face of the altimeter, the programmer has just shut down the aft engine. In OOP, the equivalent erroneous line would read ‘AftEngine. ChangeFaceColour(Red)’. This is much less likely to be written because it sounds ridiculous. In addition, the OOP language will refuse to accept this line of code, because it knows that the data structure of the object, ‘AftEngine’, does not have an associated method called ‘ChangeFaceColour’. Addressing data structures solely via their methods makes some program errors impossible, because the method has to match the object, just as in English the verb has to match the noun.

Going over to an OOP methodology has several other benefits, not the least of which is ‘inheritance’. Most of the objects we deal with in the real world are related to others. Indeed, taxonomic classification is a way of trying to organise objects into ordered groups. All birds lay eggs and have feathers. Some can fly, others cannot. Of those that cannot fly, some are penguins, some are emus, some are ostriches. Of the penguins, some live in Antarctica. Of those, one species is the King Penguin, another is the Emperor Penguin.

Each level in this classification scheme inherits the characteristics of the levels above. Thus we can confidently state that emus are flightless and also that they are birds, and hence lay eggs and have feathers. King Penguins are feathered egg-layers that cannot fly, currently domiciled in Antarctica.

We can construct the same sort of hierarchical relationship between objects. For instance, all instruments have some characteristics in common. Let’s say that they all have a face colour and a size, two characteristics that will be part of a data structure. In addition they can all be resized and moved about the screen, two methods associated with the data structure. A class called ‘instrument’ could be created that incorporated these characteristics.

Some instruments present information via a digital output. Others, such as the altimeter, use a clock-face output, which OOP allows the programmer to define as a new class of objects, called ‘analogue’. But instead of having to redesign all the characteristics of ‘instrument’ for this new class, the programmer may simply say that it inherits the data structure and methods of ‘instruments’. The only extra work required is to expand the data structure to include information about hands and add the methods necessary to manipulate them.

Of the analogue instruments, some will have an insert into the face. This might be simple, as in the case of the altimeter face in which a striped flag appears as the aircraft nears the ground. Or it might be complex, such as a graphical representation of the aircraft showing open doors, which appears in the face of the dial to indicate whether the vehicle is ready for take off. Again, these new classes of objects can inherit the characteristics of the class above, and also have new ones added.

Traditional programming methods would mean that each sub-type of instrument would have to be coded separately, wasting much programming effort. In addition, it would substantially increase the chance of errors creeping in, because there are more lines of code in which errors can hide. According to the Object Interest Group, a British association of 16 companies (including Rolls Royce, Barclays Bank, Royal Insurance and British Aerospace) set up to assess the worth of OOP to British industry, OOP can use up to 80 per cent less code than normal procedural techniques.

So who’s taking up this novel approach to programming? OOP has made that most difficult transition from academic novelty to productive tool so quietly that many computer users are unaware of the change. The first programmers to use OOP concepts in their work were those developing graphics and games software in the early 1960s. Because their work was dominated by manipulating objects on screen, they began to stretch conventional languages to accommodate OOP principles. In 1965, three programmers at the Norwegian Computing Centre in Oslo wrote the first language with objects specifically in mind. Known as Simula, for simulation language, it was a development of ALGOL, one of the earliest computer languages.

A series of object oriented languages followed in the 1970s, notably Smalltalk and Eiffel. These were faithful to the OOP philosophy, but have never become widely used outside the academic world. Some of them, Smalltalk in particular, have acquired the unenviable reputation of being very difficult to learn. To be fair to the innovators, however, it must be said that programmers, as much as anyone else, tend to be reluctant to learn new tricks.

The great acceptance of OOP began in the mid-1980s when languages that were already in widespread use, such as C and Pascal, were modified to accommodate OOP principles, becoming known as C++ and Object Oriented Pascal in the process. Programmers like learning from hybrid languages because the new concepts are presented simply as extensions of what they already know, and can be picked up more quickly.

The three biggest software houses in the world of microcomputers, the American companies Microsoft, Lotus and Borland, are all developing software based on OOP. Of the three, Borland has championed the OOP cause most strongly. The company claims that more than half of the world’s programmers buy its languages, which are now all object oriented. In addition, Borland’s applications software, for spreadsheets and databases for instance, are written with its own OOP languages.

OOP isn’t a cure for every programming ill, but it does offer a solution to some of the problems that have dogged the software world for the past few years. And one day, as your aircraft lurches down towards the runway on a foggy, turbulent night, it might just prevent the sudden unnerving quiet of a complete engine shutdown from spoiling your journey.

Mark Whitehorn is the adviser on microcomputers at the University of Dundee. His interests include teaching people to enjoy using computers and convincing the world to use software that won’t drop aeroplanes out of the sky.