object oriented design — what is it?

what is it?

70-80% of the development expenditure on the average program is spent after its first release: the 'maintenance' phase in which bugs are fixed, features are enhanced, and the program is updated to keep pace with changing domain requirements. Reducing the cost of changing and elaborating software is the main objective of object-oriented design.

The structure of an object oriented program mirrors the structure of the domain in which it works. So for example in an air traffic control system we would expect to see structures relating to the concepts that air traffic controllers think about: aircraft, flight paths, runways....
The benefit of this close simulation is that when the users talk about their needs, you can easily relate the terms they are using to the relevant parts of the program. In particular, when requirements change, you will readily be able to pinpoint which parts of the program need to be updated.

A stronger principle, adhered to (additionally to the above) in the best OO designs, is that features of the system's required behaviour are mapped onto structures within the program. This is particularly applied to features that are likely to be variable: for example, if aircraft are assigned to flight paths by different protocols in different traffic control régimes, then we would expect to find just one part of the software within which assignment (and related functions like re-assignment etc) are dealt with; conversely, in this part, nothing else is dealt with.

The benefit of this strict separation of concerns is that the behaviour of the system can be changed just by substituting one chunk of software for another; and conversely, making such a substitution should affect nothing else. Component based development is founded on this principle.

'Objects' are the structural units in OO designs. Our ATC program has an object to represent each aircraft, others to represent each flight path; and perhaps one to represent each flight path assignment protocol. Each software object is a grouping of the procedures related to simulating each real-world object, together with the data structures needed to represent its current state. For example, each aircraft will have data representing height, position, velocity; and procedures for simulating movement, projecting its track, and so on. (Software designers usually think in terms of  'class', a group of procedure and data definitions from which many objects of the same kind can be created.)

An important property of objects is 'encapsulation': the idea that only the procedures that form part of an object are able to access its data. Contrast with a more traditional scheme, in which any part of the program can access any piece of data. OO programming languages enforce this restriction; though it is also possible to follow it in any language, by deciding strict groupings of procedures and data. Encapsulation accords with the idea of mirroring the real world: to alter a plane's height, you must go through the appropriate procedures with the flight controls -- you can't just reach for the altimeter and turn it a few thousand feet up or down.

The principal benefit of encapsulation is that the designer of an object has complete control over its internal workings, and can therefore provide guarantees about its behaviour (to the designers of the other objects with which it works).  It's easier to build a large system from such well-defined pieces.

Secondarily, the internal design of an object can be altered without the changes necessarily propagating to the rest of the program. Used well, encapsulation can provide good controls on the costs of software updates.

Careful definition of the interfaces to objects is the key to 'pluggability' (sometimes called 'polymorphism' or 'substitutability'), which is the most powerful benefit of object oriented design. Your object (for example the air traffic control system) uses another for some set of functions (for example Runway Assignment): it depends only on the interface -- the set of procedures for assigning and reassigning planes --- rather than on any aspect of the internal workings of the runway assigner. This means that Runway_Assignment is actually just an interface definition, a list of procedure calls ('messages') and the specifications of what to expect of them. There can be several implementations of the interface (for example, Automatic Assignment, Controller-Assisted Assignment, ...). By choosing one or another implementation, we can assemble different systems: just in the same way that we can create different PCs or hi-fi systems by plugging in different compatible implementations of the various parts.

Taking this idea to the limit, we can make kits of objects with many interoperable pieces, which can be rapidly assembled into a variety of end products. User interface libraries are the best-known examples.

Some OO programming languages provide support for the definition of interfaces, either directly or in the form of 'abstract classes'.

complete solutions for object oriented analysis and design
(consultancy, courses, workshops, mentoring, seminars, development)

what is object oriented design? | how do you do it?
email us  or  telephone   UK: 01625 850 839    International: +44 1625 850 839