I. AN INTRODUCTION

What is an object?
Meyer, presents the following example using the object
oriented language, Eiffel :

class POINT export
x, y, translate, scale, distance
feature
x, y: REAL;
scale ( factor : REAL ) is -- Scale by a ratio of factor
do
x := factor * x;
y := factor * y;
end; -- scale

translate ( a, b : REAL ) is
-- Move by a horizontally, b vertically
do
x := x + a;
y := y + b;
end; -- translate

distance( other : POINT ): REAL is -- distance to other
do
Result := sqrt(( x - other.x )^2 + ( y - other.y )^2 )
end -- distance
end -- class POINT

This code does call for some clarification. All writing
following the double dashes is a comment. The export statement
means that the object/class can be accessed by other routines for
the specified operations.
In PASCAL, there are data structures called records.
Records are compound data structures; a record is made up of one
or more smaller data structures. However, these records are
defined only in terms of other data structures. In object
oriented programming, as can be noted from the above example,
classes define compound data types in terms of more primitive
data types and in terms of functions and procedures that apply to
a given class. Furthermore, classes, maintain their identity
only in the code; at run-time the items take on a new life as
objects.
It can be suggested that a class defines an algebra for
given instances. The values and the operations allowed on the
values are defined by a class. In the form displayed above, we
have a class; when implemented at run-time, these classes will be
objects.
Now that we've seen the basics of objects, let's take a
closer look at them, and how they are applied.

II. "OBJECT-ORIENTED-NESS" - THE BIG PICTURE

Wegner systematically describes different programming
language features which bring a language closer to
"object-oriented-ness". The first level in this direction is
described as object based. An object based language supports
objects, meaning data structures which define variables as well
as operations on those variables. Additionally, an object also
stores the most recent state of the object.
The next level would be a classed based language. If all
objects in a language must be part of a class then the language
is class based. If the property of inheritance is added to a
class based language, then the language is object oriented.
Inheritance means that the properties of a given object may be
passed down to another object. The second object could have
extra operations defined on it and thus describe a subset of the
original object.
Earlier in this paper, objects were compared to records in
PASCAL. However, PASCAL has no facilities for defining modular
objects. Though a record may be self-contained in terms of more
basic data structures, functions cannot be defined for a record.
Additionally, data hiding or encapsulation, which prevents other
modules from "peeking" at the "private" data of a given module,
is not supported by PASCAL. This is because PASCAL's scoping is
global. The only true local variables in PASCAL are those that
are declared locally in a lowest level procedure or function.
Because its data are generally global PASCAL cannot be included
among the family of object oriented languages. ( In fairness to
PASCAL, it could be argued that a binary tree consisting of
pointers to other records may define an object. The definition
of tree := tree^.left is an operation on the record named tree. )
Whereas PASCAL has no object-oriented capabilities, C
possesses these capabilities. Furthermore, it must be pointed
out that there is a difference between supporting these
object-oriented features, and merely allowing them. Thus,
Stroustroup points out that there is a middle ground of a
language enabling - as opposed to supporting - object oriented
programming. For example, a structure in C can include
declarations of simpler data types, as well as pointers to
functions. With the inclusion of pointers to functions in the
structure, operations on the structure may be defined. A smaller
structure may be included in a larger one to simulate
inheritance. Finally, in C the static declaration of variables
may be used to hide data within given modules.

III. "OBJECT-ORIENTED-NESS" - SMALLER VIEWS

Rather than take Wegner's top-down approach to defining
"object-oriented-ness", Stroustroup identifies those features
which are required of a language to be object oriented. First of
all, an object oriented language must support data hiding. Data
hiding means that variables that are declared in a given module
remain unique to that module, without the other modules having
access to those variables. Standard programming practice until
now has allowed global access to variables, which can lead to
very confusing and faulty code. Data hiding allows modules to
become "black boxes" which produce a result without their methods
being made known to the rest of the program.
A second feature of object oriented design is data
abstraction. This refers to an user defined type - in
Stroustrup's formulation. User defined types, though already
exist in languages like PASCAL (records) and C (structures), but
the handling. User defined types in object oriented design
include declaring operations for which the type is defined.
Ideally, in an object oriented environment, these types should be
initialized by a special function, and disposed of when no longer
needed.
The final and one essential property of an object oriented
language is inheritance. The implication of this previously
defined property is that the programmer should define all the
functions he wants for a given class and allow shared features to
be spread to subclasses.

IV. MULTIPLE INHERITANCE

If Mr. Smith marries Ms. Jones, their children will inherit
traits from both the Smith and Jones families. When applied to
object oriented programming this "two families" concept is called
multiple inheritance ( Needless to say, multiple inheritance need
not be limited to two classes. )
If a subclass inherits features from two or more
superclasses, it takes on the features of both of its prototypes.
Meyer considers multiple inheritance to be essential to object
oriented programming. He gives an example of an implementation
of an object called WINDOW, which requires properties to be
inherited, defining its shape ( from class SCREEN_OBJECT ), its
ability to read text ( from class TEXT ) and the ability to be
manipulated ( from class TREE ). Thus one class derives its
functionality and definition from three superclasses.
Thomas brings up a significant problem of ambiguity. If
more than one of the superclasses possesses a method by a given
name, how is this ambiguity resolved.
Stroustroup provides two possible resolutions to this
potential problem. Ambiguity is to be caught at compile time.
In C++ the ambiguous methods are prefixed by their classes.
(Much the way components of a record are accessed in PASCAL.) In
dialects of object orient LISP, the method declared first has
priority.

V. A NEW APPROACH

The big change in object oriented program is the shift in
emphasis. The standard programming paradigm throughout the
seventies - perhaps best demonstrated by PASCAL - is the notion
of a top-down structured language. Such a language could be
viewed as a subset of the more general procedural language such
as FORTRAN. The proper structured programming technique was to
define a problem, then reduce the program into smaller tasks or
modules. Thus procedures would be modularized.
This top-down approach has several advantages. First of
all, it gives the programmer an ordered approach for solving big
problems. He can view several smaller problems instead of one
large one. Additionally, once implemented, a modularized program
is far simpler to debug than a mass of "spaghetti code." Strong
typing of variables is enforced in this scheme, in order to catch
further problems. In some ways, the language PASCAL - and other
similar ones - is designed to catch many mistakes for the
programmer.
The paradigm of object oriented design takes a new focus
though. Whereas programming languages until recently have
focused on a control structures, object oriented design
concentrates on data structures. Indeed, by making a data
structure more than just a collection of smaller data structures,
object oriented design defines the operation on the data
structure.
Stroustroup points out that a top-down approach is still
needed for defining the operations on a class/object, so object
oriented design cannot completely supplant current practices.
However, there are many application where object oriented design
is advantageous. Furthermore, there are intuitive advantages to
object/classes.

VI. SPECIFIC USES OF THE OBJECT ORIENTED PARADIGM

As mentioned above, a class may describe an algebra. ( e.g.
For what range of integers does this algebra exist? What
operations are defined in this range? ) Clearly, someone doing
research in different aspects of algebra would benefit from
object oriented languages. As evidenced in the EIFFEL code that
was presented above, geometry could well benefit from the use of
object oriented code too.
Perhaps many standard applications, such as numerical
analysis, which are procedural in nature will not benefit much
from object oriented design. However, new applications which
stress user interface would benefit greatly from object oriented
design. With the tremendous proliferation of microcomputers
there has been a move towards fully exploiting the capabilities
of these machines. Towards this end, an appropriate operating
system must be developed. The widely anticipated debut of
Presentation Manager along with the already popular MACINTOSH
user interface point to the importance of a graphical interface.
A graphical interface is an excellent example of system that can
benefit from object oriented design. Thus the well-received
operating system for Stephen Jobs' new NeXT machine is based on
object oriented design.
Thompson provides a look at the NextStep operating
environment. He provides an example as to how NextStep exploits
object oriented design. The sections of the environment which
can be displayed to the user, are subclasses of the class called
View. View objects are defined not only by a coordinate system,
but also by functions which act upon them such as rotate,
translate, scale or flip. When one of these actions is
completed, the new state of View subclass is stored. When the
user wishes to examine the new appearance of a subclass he
invokes a method of the object called drawSelf:: .

VII. GENERAL USES OF THE OBJECT ORIENTED PARADIGM

In addition to this specific method of enhancing user
interface, object oriented design enhances other aspects of
programming. First of all, object oriented design leads to
reusability of code. Thus a project that needs enhancement
should not require the extensive rewriting that Wordstar required
for a recent upgrade. Cox, elaborates on the reason for this
benefit of such design.
The standard programming approach focuses on the
relationship between operators and operands. When our
applications become more complicated, we create more complex
operators out of the already existing operators. But this sets
up two distinct concepts within our programming. There are the
active operators and the passive operands. Operands only change
when acted upon by an operator. The operator/operand
relationship is affected the environment in which it appears.
The environment is responsible for controlling the sequence in
which its components appear, the location in which they appear,
as well as insuring that the relationship between the operator
and operand is consistent.
This third target of the environment's control presents
problems, because in standard practice the environment does not
always assure consistency. The example mentioned by Cox is that

of a text editor. As an operator, a text editor requires that
its operand be an ASCII file. Yet the environment fails to
ensure that the editor only view such files. It is left to the
user to assure proper usage.
The object oriented approach, or object/message model in
Cox' formulation, combine the operator and operand. Thus, as
mentioned before, an operand - in this case either a class or an
object - is defined not only by its passive components but also
by its operators - or functions. This allows for more
flexibility, because classes need not be restricted by data
types. Operations now become part of the definition of a data
structure.
It would be appropriate here to point out the conceptual
advantage of object oriented design. People in the real world,
view their surroundings in such a manner. For example we do not
generally view cars as an engine, an electronic system, an
exhaust system, a transmission and a set of wheels - at least not
until we have to make any repairs. We view a car as a mode of
transportation. Thus a car may be viewed conceptually as being
capable of holding passengers ( capacity would be its operand )
and being mobile ( movement would be its function ). In the real
world view, a car is a class or object. So object oriented
programming has the advantage putting programming into the real
world.

VIII. THE FUTURE OF OBJECT ORIENTED DESIGN

In the March 1989 issue of BYTE, an unattributed sidebar
asks the question "What Took So Long?" In other words, even
though the ideas behind object oriented design have been known
for a while, why is this programming paradigm only now starting
to gain acceptance in the programming community. The answer
supplied is "ignorance." For some time, the pioneering work in
this area was limited to the Xerox Palo Alto Research Center, so
very few people knew about it. Ignorance also played a role in
the perception of object oriented programming as being limited to
user interfaces. Many who knew about it, simply did not
understand its full range of applications.
But that's not a complete answer. Even if knowledge of
object oriented design had spread more quickly, it would only
make its way slowly into the programming community. Take ADA for
example. Despite massive government efforts for the better part
of the decade, ADA only now is starting to gain acceptance.
There are many software professionals who do not like the idea of
starting all over again. If something works why change it? (For
example, I heard a few years ago that COBOL was the most popular
computer language. That doesn't make sense because of it's
limited appeal. Yet it survives because it has been successful
for so long.) Despite all the effort and money that the
Department of Defense spent designing ADA, programmers were
probably more comfortable sticking with tried and true languages.
Only by insisting on ADA for embedded systems did the government
force the language to take hold.
Furthermore, as it was pointed out above, object oriented
design still depends on standard programming practices. The
methods, which are part of the design of the objects, still would
benefit from a top-down structured design. Second of all, one of
the more accessible object languages is C++, which is a superset
of the language C. Therefore, programmers who wish to program
using object oriented design techniques, do not have any
incentive to give up an old language. The choice now is not an
either/or choice, so the old ways will not disappear in favor of
this new one so quickly.
However, object oriented programming is clearly here to
stay. Smalltalk and C++ are available and affordable for
microcomputers. As previously mentioned, the new emphasis on
user interfaces certainly encourages a greater use of object
oriented design. Other specialized uses - such as mathematics on
the computer or artificial intelligence - will certainly be
greatly enhanced by object oriented programming. Object oriented
programming will certainly be able to carve a niche for itself in
the big world of programming.