Implementation
In principle, the phase of implementation
follows on from the design phase.
In practice, however,
the products of design may often
only be regarded as
providing a post hoc justification
of the actual system.
As noted, for instance, in [HOB87],
an object-oriented approach may blur
the distinction between design and implementation,
even to the extent of reversing their actual order.
The most important distinction between design
and implementation is hence the level of abstraction
at which the structure of the system is described.
Design is meant to clarify the conceptual
structure of a system,
whereas the implementation must include all
the details needed for the system to run.
Whatever approach is followed, in the end
the design must serve both as a justification
and clarification of the actual implementation.
This role of design is of particular importance in projects
that require long-term maintenance.
Correcting errors or adapting the functionality of
the system on the basis of code alone
is not likely to succeed.
What may help, though, are tools that extract
explanatory information from the code.
See, for example, sections [eiffel-tax] and [pde].
Testing and maintenance
Errors may (and will) occur during the implementation
as well as later when the system is in operation.
Apart from the correction of errors,
other maintenance activities may be required,
as we have seen previously.
In [Knuth92], an amusing account is given of the errors
Knuth detected in the \TeX\ program over a period of time.
These errors range from trivial typos to
errors on an algorithmic level.
See slide [1-errors].
An interesting and important question is to what extent
an object-oriented approach, and more
specifically an object-oriented implementation
language, is of help
in avoiding and correcting such errors.
The reader is encouraged to make a first guess,
and to verify that guess later.
As an interesting aside, the \TeX\ system has
been implemented in a language system called Web.
The Web system allows one to merge code and explanatory text
in a single document, and to process that document
as either code or text.
In itself, this has nothing to do with object orientation,
but the technique of documentation supported
by the Web system is also suitable
for object-oriented programs.
We will mention a Web-like system for C++
in chapter 11.
Object-oriented language support
Operationally, encapsulation
and inheritance are considered to be the basic mechanisms
underlying the object-oriented approach.
These mechanisms have been realized in a number
of languages.
(See slide [1-languages].
See also chapter 5 for a more complete overview.)
Historically, Smalltalk is often considered to be the
most important object-oriented language.
It has served as an implementation vehicle
for a variety of applications (see, for instance, Pope, 1991).
No doubt, Smalltalk has contributed greatly to the
initial popularity
of the object-oriented approach,
yet its role is being taken over by C++, which
now has the largest community of users.
Smalltalk is a purely object-oriented language,
which means that every entity, including
integers, expressions and classes, is
regarded as an object.
The popularity of the Smalltalk language may be attributed
partly to the Smalltalk environment,
which allows the user to inspect the properties of all
the objects in the system
and which, moreover, contains a large
collection of reusable classes.
Together with the environment, Smalltalk
provides excellent support for fast prototyping.
The language Eiffel, described by [Meyer88],
may also be considered as a pure object-oriented language,
pure in the sense that it provides classes
and inheritance as the main device with which to
structure a program.
The major contribution of Eiffel is
its support for correctness constructs.
These include the possibility to specify
pre- and post-conditions for methods, as well
as to specify a class invariant, that may
be checked before and after each method invocation.
The Eiffel system comes with a number of libraries,
including libraries for graphics and window support,
and a collection of tools for browsing and the extraction
of documentation. See also chapter 11.
The C++ language (Stroustrup, 1991) has a somewhat different history.
It was originally developed as an extension of
C with classes.
A primary design goal of C++ has been to develop
a powerful but efficient language.
In contrast to Smalltalk and Eiffel,
C++ is not a pure object-oriented language;
it is a hybrid language in the sense that it allows us
to use functions in C-style as well as object-oriented
constructs involving classes and inheritance.
Much of the support that comes with Smalltalk
and Eiffel may be acquired for C++ in the form
of third party libraries or toolkits.
A number of these libraries and toolkits
are discussed in chapter 11 and 12.
Currently, a number of research groups
(including my own) are working on extending
C++ with concurrency.
An overview of these efforts and the conceptual
issues involved is given in chapter 6.
Smalltalk -- a radical change in programming
languages
Eiffel -- a language with assertions
C++ -- is much more than a better C
- the benefits of efficiency
DLP -- introduces logic \c{into object orientation}
- development of knowledge-based systems
slide: Object-oriented languages
As the final language in this brief overview,
I wish to mention the distributed logic programming
language DLP (see Eliëns, 1992).
The DLP language combines logic programming
with object-oriented features and parallelism.
I mention it, partly because the development
of this language was my first involvement with
OOP.
And further, because it demonstrates
that other paradigms of programming,
in particular logic programming,
may be fruitfully combined with OOP.
The language DLP provides a high level vehicle
for modeling knowledge-based systems
in an object-oriented way.
A more extensive introduction to the
Smalltalk, Eiffel, C++ and DLP languages is given in the appendix.