Object Orientated Programming (OOP)

Programming is the process of creating PC based solutions to computer - tractable problems. The program is a solution to a problem in a form that can be understood by a PC. A definition of a computer prog might be :

" a computer program is an abstraction of both the real world of the problem it is intended to solve and of the m/c by which it is executed. "

There is an alternative definition of a computer prog :

This definition encapsulates the description of a computer prog as a set of instructions to follow (the algorithm) together with all the necessary info (the data) to produce a solution to a problem. The data is the info used by a prog and created by a prog. We can think of a prog as a data transformer converting input data into output data.

'Conventional' proging with 'conventional' languages can be structured, i.e logical and easy to follow and involves sectioning the original problem into small prog units each of which is self contained and can be tested separately.

The main prog can then consist of a series of instructions each sending the PC to a particular unit or subroutine which it carries out and then returns. With a top-down approach the prog is written in units in the same way as the problem was originally solved and a flow-chart is usually important to show the flow of logic and assist in prog development.

If OOP is thought of as an innovative approach to programming or the programming paradigm for the 1990's it is first best to describe a background philosophy, much of the same philosophy could be thought of as a applicable to the design of any program using conventional techniques also. However the differences will be shown in the course of the dialogue.

Specification of the problem to be solved is not always as easy as it sounds the act of being specific relieves the problem of ambiguity, clarifies the problem and often allows a solution to be more easily constructed. The specification in C++ takes the form of a structured statement of the problem outlined below but not described in detail :

• Module name. *

• Purpose. *

• Module type. *

• Interface.

• Input.

• Output.

• Pre conditions.

• Post conditions.

• Side effects.

* = mandatory

Each of the sections of the specification has a role to play but it should be noted that any one module specification does not have to contain every section. For C++ it is important to set out the format for the specification of code modules and by modules we mean progs, classes (see later) and functions. Every code module should be supported with a specification following a given archetypal format from which there should be no deviation. This more formal specification of a problem will have the added advantage of making any assumptions explicit.

Hopefully, following a careful specification of the problem the implicit assumptions of the original problem statement have been clarified and explicitly stated. However we may still not be certain these assumptions are valid and they may carry with them inferences that may prove false. The importance of isolating the assumptions in a problem and questioning their validity cannot be over-emphasised. Assumptions are important in finding creative solutions; the fewer the assumptions the more general the problem and the more scope for possible solutions. However, the more critically you examine the constraints (the assumptions) on a problem the more accurately you can define the problem and the easier it will be to check possible solutions for validity.

Many problem statements contain redundant info and there is no obligation to use this info except for validating the solution, and a solution that uses no more info than is strictly necessary is more general than one that uses unnecessary info. Redundant info can also act as 'noise' obscuring the problem.

One advantage of breaking the problem down into manageable pieces is the ability to concentrate on one aspect of the whole, generally a piece of the problem which can be solved more easily. This also raises confidence and gives more time for the harder parts. The technique results in a factorisation of the problem into a smaller set of self contained sub problems. Unfortunately one of the side effects of this approach has been to concentrate on the functional aspects of the components of the problem. That is, the emphasis is on analysis of 'how' the problem (or system) functions in order to compose a solution to satisfy those characteristics.

A more profitable approach in many ways is to identify the essential components (or objects) of the problem and analyse what interactions occur between those components. If we can then model those components and interactions then not only do we have a specification of the problem but, if we can realise this model,

we have a solution as well. We could even use those components again and remodel their interactions to produce a solution to a different problem. This is the basis of object orientated design and object orientated proging (OOP).

The majority of deep mathematical proofs have been worked backwards from the solution. Maze problems are a simple example where working backwards helps and similarly there is a great deal to be learnt by studying and amending working progs rather than creating progs from scratch.

Abstraction is the process of concentrating on only the essential properties of an object which are relevant to us and disregarding the rest. In terms of everyday life we don't worry about how things work internally, such as a video recorder, only that it does what it is supposed to do when we use it properly through the controls (the interface).

Abstraction is also important in the way we recognise things such as houses, cars, people, dogs, and so on because we remember the essential features of these entities, not the entities as individuals. We abstract the important things which make them what they are and classify them appropriately.

This provides the basis for a sound approach to the design of reliable software. In dictionary terms, something abstract is essentially something unreal and when considering either buildings, cars or airplanes these words relate to a whole class of things in each case. Each word conjures up a mental picture of what they are and what they do. The reader will know what is meant by the class 'car' (although a pygmy may not). We can drive cars we have never seen before because we know that most cars have the same characteristics (let us assume we can cope with a slight variation of the controls such as where the horn is located).

OOP attempts to abstract problems in a special way into software objects that relate to real world objects that we are concerned with. Quite often the abstraction applies to special kinds of abstract software entities or structures, such as stacks or queues that help us solve a variety of different problems. The idea is to model the problem domain into a set of software-equivalent objects which we can manipulate and control (like our car) in order to solve the problem.

Consider the design of a PC. A PC is essentially modular in design and may be broken down into a finite set of complex sub-systems, such as the circuit boards, processors, memory, disk drives and so on, each of which has an interface to other parts of the system. We don't have to know how the internal parts of these subsystems work, only their characteristics and we can purchase a variety of add-ons or upgrades

This is the essence of object orientation in software terms using pre-defined and well engineered software objects to solve our problem. However someone has to design these objects and, like their electronic analogies, that can be a tricky and time consuming process. However we do not have to keep 'redesigning the wheel' every time we want something new. OOP allows us to add to what we have already created to make more specialised objects. This is called inheritance and is an important part of the OOP philosophy.

This leads us to the concept of a so called abstract data type. From what was said previously, an abstract data type is one in which we are principally concerned with what it can do for us through an interface rather than how it does it. We strip away the implementation details and worry only about the properties essential to their use (such as the position of the car controls.) It allows us to structure the solution to our problem in abstract terms at a 'high' level rather than worry about the means by which it is to be implemented internally. This requires some means of hiding the internal workings and data elements of the object from the user and is called info hiding. This is very important in the design of software modules where we don't want our specially engineered tool misused and ensuring its portability in solving other problems.

To conclude, C++ compiled code combines the elegance and compactness of C with the ease of development and maintenance afforded by object orientated proging. There is no questioning the fact that C and C++ are at present the dominant languages for PC proging and are set to remain so, especially if developers wish to keep pace with the leading edge. DOS, Wins, Wins NT and OS/2 are all written in C or C++.

The guts of modern apps are embodied in a Dynamic Link Library (DLL) written in C, with the 'front end' being created in a higher level Graphical User Interface (GUI) based language like Visual Basic. At the low end, it used to be common for 'critical' code to be hand-crafted in assembler. However these days, increasing emphasis on portability has made this practice less desirable, while more advanced processors mean that compiled code can run faster because of obscure optimisations which no human could emulate.