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)
