21-08-2012, 03:03 PM
What is ‘‘Object-Oriented Programming’’? (1991 revised version)
Object-Oriented.pdf (Size: 51.6 KB / Downloads: 16)
ABSTRACT
‘‘Object-Oriented Programming’’ and ‘‘Data Abstraction’’ have become very common
terms. Unfortunately, few people agree on what they mean. I will offer informal
definitions that appear to make sense in the context of languages like Ada, C + +, Modula-
2, Simula, and Smalltalk. The general idea is to equate ‘‘support for data abstraction’’
with the ability to define and use new types and equate ‘‘support for object-oriented programming’’
with the ability to express type hierarchies. Features necessary to support
these programming styles in a general purpose programming language will be discussed.
The presentation centers around C + + but is not limited to facilities provided by that language.
Introduction
Not all programming languages can be ‘‘object oriented’’. Yet claims have been made to the effect that
APL, Ada, Clu, C + +, CLOS, and Smalltalk are object-oriented programming languages. I have heard discussions
of object-oriented design in C, Pascal, Modula-2, and CHILL. As predicted in the original version
of this paper, proponents of object-oriented Fortran and Cobol programming are now appearing. ‘‘Objectoriented’’
has in many circles become a high-tech synonym for ‘‘good’’, and when you examine discussions
in the trade press, you can find arguments that appear to boil down to syllogisms like.
Programming Paradigms
Object-oriented programming is a technique for programming – a paradigm for writing ‘‘good’’ programs
for a set of problems. If the term ‘‘object-oriented programming language’’ means anything it must
mean a programming language that provides mechanisms that support the object-oriented style of programming
well.
There is an important distinction here. A language is said to support a style of programming if it provides
facilities that makes it convenient (reasonably easy, safe, and efficient) to use that style. A language
does not support a technique if it takes exceptional effort or skill to write such programs; it merely enables
the technique to be used. For example, you can write structured programs in Fortran, write type-secure programs
in C, and use data abstraction in Modula-2, but it is unnecessarily hard to do because these languages
do not support those techniques.
Support for a paradigm comes not only in the obvious form of language facilities that allow direct use
of the paradigm, but also in the more subtle form of compile-time and/or run-time checks against unintentional
deviation from the paradigm. Type checking is the most obvious example of this; ambiguity detection
and run-time checks can be used to extend linguistic support for paradigms. Extra-linguistic facilities
such as standard libraries and programming environments can also provide significant support for paradigms.
Problems with Data Abstraction
An abstract data type defines a sort of black box. Once it has been defined, it does not really interact
with the rest of the program. There is no way of adapting it to new uses except by modifying its definition.
This can lead to severe inflexibility. Consider defining a type shape for use in a graphics system.
Assume for the moment that the system has to support circles, triangles, and squares. Assume also that you
have some classes.