Is Object-Oriented Programmin g
Structured Programming ?
Bernd Muller
Fachbereich Informati k
Universitat Oldenbur g
D-2900 Oldenbur g
Bernd . Mueller©Informatik .Uni-Oldenburg . D E
Abstrac t
Object-oriented programming is one of today's buzzwords . On the one hand it is a programmin g
paradigm of its own right . On the other hand it is a set of software engineering tools to build mor e
reliable and reusable systems . One other kind of programming style, which has alr eady shown its
power on this field is structured programming .
In this paper we look at the relationship between structured programming and object-oriente d
programming . We give a definition of structured programming and check the object-oriented features
encapsulation, inheritance and messages for compatibility . Two problems arise . The first addresse s
interfaces and inheritance, the second polymorphism and dynamic binding .
We do not end with an answer like yes or no, but try to give a basis for further discussions .
This may help to classify object-oriented programming into a wide range of tools for compute r
programming and computer science . It may also help to abandon the hypothesis that object-oriente d
programming is the solution to all the problems .
1 Introductio n
Much work has been done in the field of comparing Structured Programming (SP) with Object-Oriente d
Programming (OOP), or working out the relationship between both . For example, Grogono [13] promises
that a carefully designed Object-Oriented Programming Language (OOPL) corresponds to the requirements of SP . Blaschek [4] shows how objects can be implemented in Modula-2, the programming languag e
showpiece of SP . Edelson [12] compares Modula-2, C++, and Smalltalk-80 in terms of engineering larg e
software systems effectively, which is the target of both, SP and OOP . Meyer [18] tries to motivate tha t
Object-Oriented Design (OOD) and OOP, especially the language Eiffel [19] meets the demands of S P
and, moreover, goes beyond it .
In this paper we also want to focus on the relationship between SP and OOP, but more detaile d
and comprehensive than done by that previous work . The above papers did not do that, because thei r
primary purpose was completely different . We think the relationship between SP and OOP is not obviou s
enough and it is worth to look about it .
Both, SP and OOP are popular today although SP has a longer history . The current popularity o f
OOP and the connection to SP was pointed out by Rentsch :
"What is object oriented programming? My guess is that object oriented programming wil l
be in the 1980's what structured programming was in the 1970 ' s . Everyone will be in favor of
it . Every manufacturer will promote his products as supporting it . Every manager will pay
lip service to it . Every programmer will practice it (differently) . And no one will know jus t
what it is . " [22]
57
ACM SIGPLAN Notices, Volume 28, No . 9, September 1993
Beside the similarity in popularity SP and OOP are different paradigms', but, with respect to som e
metric or (partial) ordering, is it possible to order them or are they incomparable? We think that SP is a
more general term than OOP . Thus, we have to show that every object-oriented program is a structured
program . Or, to avoid some paranoiac programs, that every concept of OOP meets the demands of SP .
The notion of OOP is used by everyone, as mentioned in the above quotation, but used differently .
The notion of SP is also widely used but has a somewhat more exact definition . Nevertheless, we have t o
define the notions of SP and OOP . In OOP we concentrate on inheritance, encapsulation and the messag e
passing mechanism . We exemplify the relationship of these central object-oriented features to SP .
The rest of this paper is organized as follows . Section 2 introduces the notion of SP, section 3 th e
notion of OOP . Section 4 examines more closely the relationship between both paradigms . The pape r
concludes with section 5 where we summarize our results .
2 Structured Programmin g
SP is a very ol d 2 method to construct computer programs . Founded by [10] many people [29, 30, 15] have
acknowledge this technique and SP has become the state of the art in programming . Nevertheless, we
were not able to find 3 a complete but short enumeration of SP feature (a definition) . We try to do thi s
ourselves, without claiming to be complete . But, to apologize for incompleteness, we think it is enoug h
for our comparison .
The method or paradigm of SP consists (at least) of the following (taken from [11, 10, 30, 15]) :
SP1 The problem is decomposed into independent subproblems (see SP2) . This decomposition recurse s
until the subproblems are atomic and can be solved .
SP2 The subproblems are connected by interfaces, and can therefore be solved independently .
SP3 The structure of (sub)problem(s) and (sub)solution(s) are (almost) identical .
SP4 There is a strong correspondence between the static description of the algorithm and its dynami c
behavior (run-time) .
SP5 It is `easy' (the structures make it easy) to convince one about the correctness of the solution .
SP6 The only allowed control structures are selection, sequence, and repetition .
SP7 There is some block structure (visibility, scope of names )
This definition should be used as is, i . e . some interpretation should be possible . If we do not allo w
this we can stop after SP1 . SP1 is a point of design and mainly constitutes top-down design . On the
other hand OOP favors bottom-up design . Sometimes this is not stated explicitly, but it is agreed upo n
that DOD and OOP is done by composing objects or classes together, which is certainly a bottom up technique ([31] and [20] give an overview of ODD techniques, [17] and [5] are two well establishe d
methods) . We want to compare SP and OOP on the programming language level, not on the desig n
level . Therefore, SP1 is not so much important . But the problem remains . For example to satisfy SP5 ,
i . e . real correctness, formal verification techniques are necessary, which do not exist for SP and OOP ,
at least for complex enough (real life) applications . Therefore keep in mind that the list should act as a
direction, not as a fixed mark .
'We think this is obvious and do not proof it . The above mentioned authors [13, 4, 12, 18) have the same opinion .
Nevertheless, they will may be not agree with the following statements .
2 In terms of computer science .
3 Maybe due to our own inability .
58
3 Object-Oriented Programmin g
OOP is not a new programming paradigm . Simula in the late 60th and Smalltalk in the 70th started th e
development of a new programming paradigm, but did not succeed (in terms of wide spread use) . Th e
software crisis and a new interpretation of OOP, namely not as a programming paradigm, but as a set o f
software engineering concepts to produce better programs, has pushed OOP to the top . Cox [9], Meye r
[17] and many others argue that object-oriented concepts will produce programs which are superior tha n
conventional programs in terms of correctness, robustness, extendibility, reusability, and compatibility .
It is out of the scope of this paper to give a comprehensive introduction into OOP . A very extensiv e
discussion of central object-oriented features can be found in [28] . Almost every textbook on OOP ca n
be used for introductory purposes . Especially to mention is [6], which exemplifies the concepts into fou r
different OOPLs, making clear the distinction between concepts and different implementation of thi s
concepts .
For the discussion in this paper we will concentrate on encapsulation and inheritance`, which Co x
identifies as the central points, and in addition the message passing concept .
3 .1 Encapsulation
In OOP each data-item is joined exclusively with the procedures manipulating this data-item . Th e
attached procedures of a data-item are called methods, all methods together are called interface, the dataitem together with its methods is called object . Because it is not allowed for unattached procedures t o
manipulate an object the data is encapsulated . Therefore the effects of changing data and/or procedure s
is always restricted and easy to localize .
Snyder requires for real encapsulation tha t
" . . .one characteristic of an object-oriented language is whether it permits a designer to defin e
a class such that its instance variables can be renamed without affecting clients ." [23 ]
3 .2 Inheritanc e
Inheritance is a technique which enables the reuse of behavior s of already defined classes (a class is a
template from which objects can be created) in the definition of a new class . Inheritance plays such a n
important role in OOP becaus e
"Inheritance can express relations among behaviors such as classification, specialization, generalization, approximation, and evolution ." [28 ]
Beside this conceptual benefits inheritance helps to avoid the duplication of code and the need fo r
coding from scratch . It is therefore a tool to engineer software in a better way, too .
3 .3 Message passin g
A message is sent to an object and represents a request to perform some action . It is in the responsibility
of the receiver how to react . Thus, it is possible that different objects react differently after receiving th e
same message . While this is a high-level concept which influences design (called responsibility-drivendesign [31]) on the lower level of language implementation there is one more important difference to
conventional procedure calls . Procedure calls are bound early (at compile or link time) to some cod e
fragments, while messages trigger the execution of some code lately (which code to execute is determine d
at run-time) with respect to the above scheme of responsibility .
4 While inheritance is really new, encapsulation is also possible in many other languages but mostly not enforced .
5 And therefore of code .
59
4
Compariso n
There are many problems in comparing SP and OOP or, what we have in mind, to check object-oriente d
features for compatibility with SP . The above remarks about the use of SP1 to SP7 are also valid whe n
using the definitions of encapsulation, inheritance, and messages . [24] and [28], for example, show a wid e
range of possible interpretations . But even if we allow some interpretation of the defined concepts, i s
it enough to compare concepts and paradigms? Is the result of such a comparison satisfactory if th e
concepts are such ideals that there exists no real language implementing it? Therefore, we do not onl y
discuss concepts but also include some existing languages into the discussion . On the side of SP we us e
Modula-2, which is a clear and clean implementation of an imperative language and well suited for SP .
On the side of OOP we have to take into account much more languages, because the market of OOPL s
is much more in change . The chosen OOPLs are Objective-C [9], C++ [25], Eiffel [17, 19] and Modula- 3
[16, 14], the most popular OOPLs in concepts and distribution today .
The three main features of the object-oriented paradigm and the seven items of SP define a table wit h
21 fields . Some of the fields will be empty, because the concerned concepts are orthogonal . Some field s
will need much more attention than others . In the next three sections we try to fill in the columns o f
encapsulation, inheritance and messages step by step and summarize at the end, giving the constructe d
table .
4 .1 Encapsulatio n
Because encapsulation was not newly introduced into the programming methodology by OOP we want t o
discuss it first . SP1 is, as mentioned already, a question of design . Encapsulation is an implementatio n
technique which enforces interfaces (a consequence of SP1, see SP2), but both are not related directly .
SP2 is still on the design or concept level but because of SP3 the demanded interface is mapped directl y
to the implementation . Therefore it is obvious that encapsulation fulfills SP2 . Moreover, if the OO D
phase comes up with a net of communicating objects these can be implemented in accordance to SP3 .
To be fair we cannot help saying that there are some difficulties with object-oriented encapsulatio n
and SP2 and SP3 . Suppose there is an object-oriented car, which breaks down . Is the car able to
repair itself, or is this done by a mechanician? This is the time where SP3 comes into play . If we wan t
to have a model of the real world the mechanician has to do it but this is forbidden by the concep t
of encapsulation . There is a way out in C++, where so-called friend-functions are allowed to acces s
data of objects of different classes . But, to repeat, this hurts the notion of encapsulation s , We thin k
a similar mechanism is necessary in all object-oriented languages, if we want to fulfill SP3 . Truly, i t
hurts encapsulation, but this concept modification is acceptable because a class has to declare his friend s
explicitly. Our world doesn't exist of independent active objects, there are also many objects witch ar e
passively manipulated by other objects .
Encapsulation is compatible with SP4 if we are allowed to interpret SP4 more liberally . SP use s
algorithmic decomposition in the design phase, which yields a description of the algorithm, the one poin t
examined in SP4 . OOD uses object-oriented, i . e . a data-centered kind of decomposition yielding a n
other type of description . If this difference is accepted we can conclude that encapsulated objects reall y
reflects the design of independent agents at the level of implementation .
An observation worth to mention is that object-oriented interfaces have a finer granularity as reache d
by conventional mechanisms . To see this we look at the interface mechanism of Modula-2 . To obtai n
real abstraction (an approximation of ADTs) we have to use opaque types . In the implementation o f
this type the procedures can access all internal data of all elements of this type, while in object-oriente d
languages the access is restricted to the object associated with the procedure, namely the receiver o f
the corresponding message 7 . This difference of accessibility is what we mean with finer granularity o f
interfaces . On the one hand a type has an interface, on the other hand each object (an element of a
6 Many other features of C++ also hurt object-oriented ideas, because C++ was designed to be as efficient as possibl e
and to be upward compatible with C .
'One more time C++ doesn't fit into this scheme, because an object can access attributes of all other objects of th e
same type .
60
type) has its own interface (truly, it is the same interface for all elements of one type, but with regard t o
accessibility each one has its own interface) .
As stated before we do not want to discuss SP5 at a formal level . [10] uses enumerative reasoning ,
mathematical induction and abstraction as three aids in proofing correctness of solutions . Abstractio n
and a better `understanding' of programs are proposed as alternatives to the more formal techniques 8 .
Encapsulation is one of the best possibilities to obtain abstraction and better understanding of programs .
Encapsulation enforces interfaces which are necessary to abstract from implementation . Further, becaus e
the interfaces have to be respected and no work-around is possible side effects will never happen, makin g
programs easier to understand .
SP6 was mainly formulated to avoid unrestricted use of gotos . It of course includes procedure calls ,
which are a kind of sequences . Because encapsulation is a syntactic mechanism to restrict the scop e
of (data) identifiers it is not related to SP6, but strongly addressed by SP7 . SP7 follows the idea tha t
identifiers should be known as local as possible and as global as necessary . Object-oriented encapsulatio n
has the same root but is reduced to data (identifiers) . Classes (or types 9 ) are global, methods too . Bu t
this is one more time founded by different design and philosophy : An object-oriented program is a se t
of objects, each object communicating possibly with each other . Taking for example block nesting fro m
SP7, what is the meaning of nested classes or nested methods ?
Very different from concepts are the OOPLs we are looking at . The reason for this is that they inheri t
from their base languages C and Modula-2 . For example, in C++ you cannot nest functions, becaus e
you cannot in C . In Modula-3 you can because you can in Modula-2 . In Modula-3 it is also possible to
hide identifiers (constants, types, variables, procedures, modules) in a block-oriented manner as you ca n
in Modula-2 1 0
4 .2 Inheritanc e
As mentioned earlier, inheritance can be seen as a conceptual relation and also as a special programmin g
technique . SP1 addresses the first interpretation, which is a question of design and not implementation .
Booch [5] classifies decomposition into algorithmic and object-oriented decomposition, and asserts tha t
SP uses algorithmic decomposition . While this is surely true, SP1 is general enough to allow bot h
interpretations, as well as other kinds of decomposition .
There is also another difference in decomposition, which we will call vertical vs . horizontal decomposition . Algorithmic decomposition yields a tree of tasks [5], where the subtrees of a node are the subproblem s
of the decomposed node problem according to the recursive definition of SP1 . Object-Oriented decomposition yields a flat partition of all concerned objects . After this the process of discovering inheritanc e
begins, yielding a graph of object classes connected by specialization and/or generalization .
Thus both methods end with a hierarchical structure . But with algorithmic decomposition the roo t
represents the problem started with, while with object-oriented decomposition the problem is modelle d
by the interaction of instances of graph nodes .
We have already discussed interfaces (SP2) in the encapsulation section . Inheritance also touches interfaces, because inheritance establishes a new kind of interface, not known in conventional programming .
In OOP objects are distinguished in suppliers and consumers :
"Object-oriented programming is . . . a way for code suppliers to encapsulate functionality fo r
delivering to consumers ." [9] 1 1
Object-oriented interfaces are most often discussed in the literature as external interfaces, i . e . establishin g
a supplier interface consumers can use . Snyder recognized in 1986 that there is also an interface fro m
parent classes to inheriting classes [23], which we will call inheritance interface in the following . If on e
follows the requirements of encapsulation (section 3 .1) it should be allowed to reimplement a class, whil e
can also think of systematic testing or other popular and widly used technique s
"We do not want to differentiate them in this paper, because this would make things much more complicated . [1, 3, 8]
can be used to see the differences .
10 See also the discussion of modules in the next section .
11 For a detailed representation of the analogy to hardware design, where new systems are built by plugging standardize
d
ICs together, see also [9] .
'You
61
keeping the inheritance interface, and all descendants behave well . This is in fact true for all of the popula r
object-oriented languages . But the reason is the non-existence of the inheritance interface . Therefore th e
whole implementation is implicitly the interface 12 and we are not allowed to change it .
In [27] the two kinds of interfaces are called data abstraction and super-abstraction, the first used b y
objects requesting actions from other objects, the second used by classes to inherit implementation . Sinc e
both abstraction concepts are orthogonal Wegner concludes that super-abstraction can be weakened, fo r
example becaus e
"Viewing inherited instance variables as part of an enlarged self also suggests direct accessibility ." [27 ]
While this is true, from a software engineering point of view the loss of interfaces is exactly that dange r
OOP has to fight against .
Looking back to SP2 we can summarize that an object-oriented language has to supply two kind s
of interfaces . External interfaces, supplied by all object-oriented languages (by definition) and an inheritance interface (not supplied by the languages of our scope, nor by any other language known by th e
author) . The implicit definition of an inheritance interface by the implementation surely hurts SP2 i f
the subproblems we want to solve are ancestor-descendant problems, because changes in the ancesto r
influences the descendant .
Inheritance addresses SP3 in a clear way. If we have detected specialization and generalization in th e
object-oriented design process we use inheritance to implement the corresponding classes . Since we us e
an adequate design the solution is naturally developed from this .
SP4 and SP5 are also related to inheritance, but we want to discuss it in the next section, becaus e
this subjects are also strongly connected to message passing .
SP6 is not concerned by inheritance at all . Inheritance is a programming technique for code reuse no t
for control structures
SP7 demands some block structure, which is implemented in conventional languages mainly by procedures and modules . The visibility rules of both can be taken from Figs 1 and 2 . Because procedure s
can also be found in a similar shape in OOPLs (namely methods, differences are mentioned at variou s
places in this paper) we concentrate on modules l 3
Figurel : Procedure visibility rule s
OOP uses classes as the main structuring mechanism . Figure 3 shows the visibility rules . Becaus e
methods build the (implicit) interface of a class (more precisely of objects) and attributes are (implicitly )
hidden, methods are globally visible, as well as objects, and nothing else . Globally visible methods ca n
be used in message expressions and a class can inherit from other classes (see the discussion of differen t
class interfaces above) . One thing not obvious from the figures is a difference in the exploding arrow .
The class arrow is transitive while the method arrow is not (inheritance is transitive, import not) .
The graphical representations of modules and classes are very similar, but, as we have shown, ar e
different . Current research [26] goes one step further . Modules and classes do not have to be unified ,
12We know of the private declaration of members in C++, but nevertheless recompilation is needed if ancestors ar
e
changed . The members are inherited (in memory layout), but cannot be accessed .
'3 Modules were introduced approximately at the same time as SP [21] . Therefore we are not sure if SP7 applies originall y
to modules, but nevertheless we suppose it this way .
62
Figure2 : Module visibility rule s
global methods
inherit
Figure3 : Class visibility rule s
because the underlying notions of import and inheritance are very different . It is out of the scope of
this paper to examine more closely this topic . However, the mentioned research concludes that OOPL s
should offer modules too, which enables us to finish our discussion of SP7 . OOP offers (can offer) method s
(procedure-like structuring) as well as classes and modules, which is enough to satisfy SP7 .
4.3 Messages
Messages are mainly a way to call methods alternatively to normal procedure calls . Additionally, o n
design level they allow responsibility-driven-design already addressed in the last section . However, thi s
question of design is not related to SP1 . Messages are not related to SP2, too . The only connection i s
the possibility to use interfaces to type check message expressions, but this is not the intended use o f
SP2 . Also messages do not violate SP3, because they can be seen as more general procedure calls . Muc h
more attention has to be taken to examine the relationship to SP4 and SP5 .
Because our definition in 3 .3 was a bit superficial we examine some facts more closely now . In definin g
methods it is allowed for different classes to define different methods with the same signature . This i s
known as polymorphism, or more precisely, overloading, a special kind of ad hoc polymorphism [7] .
For example, if a graphical object receives a rotate-message it will execute his appropriate method ,
which rotates itself with a predefined angel, say 90 0 . In contrast a member of a democratic society wil l
change his seat with a colleague if he receives a rotate-message . Another kind of polymorphism, calle d
inclusion polymorphism, is encountered when class circle inherits form class graphical . While rotat e
in graphical has to do a hard job circle can overwrite the inherited rotate leaving the method bod y
empty, because there is nothing to do . In a strongly typed language the compiler can check staticall y
the correctness of rotate message expressions, but it is not determined until run-time which of the bot h
rotates to use, if the receiver is of type graphical . In this case the receiver can be indeed a graphical ,
but also a circle and binding of the message to a method can only be done at run-time, when it is clea r
of which type the receiver actually is .
Polymorphism and dynamic binding enables software reuse, easy maintenance and extensibility, promised by OOP . In comparison to conventional programming we think that a change in binding time doe s
not hurt SP4 . Moreover, the overloading kind of polymorphism is already used in conventional languages, for example binary plus for integers and reals . Inclusion polymorphism is used (should be used) t o
63
specialize behavior in a subclass in a conformant manner, and therefore does not hurt SP4, too .
Problems may arise with SP5, because with polymorphism and dynamic binding it is possibl e
1. to customize libraries, an d
2. to call new code from old code .
The first situation takes place when you declare a library class as an ancestor for a class you are defining .
In verifying your new class the only help you get is a black box saying `the ancestor class is correct' ,
which is not necessarily enough for your work" . To see this you have to recognize the difference from a
procedure call where the procedure is taken from a library and the library is verified already .
The second situation takes place when we expand existing software . For a simple example remember
our graphical objects and a display manager sending rotate messages to such objects . If we additionall y
implement a new subclass of graphical we do not have to change anything in the display manager ( a
great object-oriented benefit), because the new objects understand rotate messages although rotat e
methods can be different . But how to convince one about the correctness of the solution? It is not enoug h
to look at the new code, you have also to look a second time at the display manager (which surely no t
corresponds to ` easy to convince', not necessarily in this example, but the problem exists) . Moreover on e
can state that it is never possible to convince one finally about the correctness of a solution, becaus e
each new class can enforce to restart the process .
We have already expanded SP6 to procedure calls . This is why messages fit nicely into SP6 . Ou r
comparison is closed with the establishment that messages are not related to SP7 .
5
Conclusio n
The results of the comparison is summarized in the following table . The entries of the table are no t
related, fulfills, sd (short for some discrepancies) and violates with the obvious meaning . Because w e
have investigated concepts and existing OOPLs some fields are of the form concept/languages .
SP1
SP2
SP3
SP4
SP5
SP6
SP7
Encapsulation
not related
fulfills
sd / sd
fulfills
fulfills
not related
sd / fulfills
Inheritance
fulfills
sd / violates
fulfills
see message column
see message column
not related
fulfills
Message s
not relate d
not relate d
fulfill s
fulfill s
violates
fulfill s
not related
In this paper we have tried to define the term Structured Programming in a way which enable s
us to test different programming techniques for compatibility . We have examined the central objectoriented features encapsulation, inheritance and messages according to these criteria . When we starte d
this research our feeling was that every object-oriented program is structured in the sense of SP . I t
was surprising that there are two problems with OOP and SP . The first addresses inheritance which i s
propagated to improve system maintenance capabilities, and the relation to interfaces, a demand of SP .
Some authors [23, 27, 28] discovered the need for two kinds of interfaces of OOPL, one for objects sendin g
messages and one for classes inheriting code . There is no general agreement on this in the object-oriente d
community and the existing popular OOPLs do not offer this second kind of interface . Therefore th e
following problem with software maintenance can arise . Suppose a Modula-2 module which has to b e
recoded . Because the definition module remains unchanged you only have to recompile the change d
implementation module and link it with the rest . In an object-oriented system the recoding of a clas s
does not influence clients of the first type, too . But clients of the second type, namely inheriting classes
14
We are no specialists in verification, but we think it is obvious that standard techniques, informal as well as forma l
ones, can not handle such situations, which do not arise with conventional programming . At least they have to be adopte d
for new situations within OOP .
64
are affected and, may be, have to be adopted. Because inheritance is transitive this can cause exponentia l
change in subclasses in the worst case .
The second problem concerns the weak definition "it is `easy' to convince" . It is already hard t o
convince one about the correctness of simple imperative programs . But, as we have shown, it is muc h
more harder if polymorphism and late binding come into play . Although we have taken SP5 from a
historical manifesto [10] we are not sure if such a weak definition is enough to condemn OOP . But, as w e
have shown, there is at least a harder work to do and this work has to be clone repeatedly .
One can disagree with this results at various points . The most important is the definition of SP.
Because SP1 – SP7 are picked up from different papers one can state that they do not constitute SP as a
whole . Another point is the liberal interpretation of the above items . But a more restricted interpretatio n
would make things worse and, may be, show that OOP is very different form SP . Additionally we have
omit some more aspects of OOP, like concurrency, persistency, delegation, subtyping vs . inheritance an d
so on . These make things more complicated and should be tackled in some future work .
Remark : It turns out that the two problems are caused by two object-oriented concepts or possibilities ,
namely inheritance and the possibility to call new code from old code . A programmer is free to decid e
to use an OOPL and also the inherently connected problems if he wants to benefit from the undoubte d
great advantages of OOP .
References
[ 1 ] Pierre America . Issues in the Design of a Parallel Object-Oriented Language . In [2], 1989 .
[2 ] Pierre America and Jan Rutten . A Parallel Object-Oriented Language : Design and Semantic Foundations . PhD Thesis, University of Amsterdam, 1989 .
[3 ] Pierre America and Frank van der Linden . A Parallel Object-Oriented Language with Inheritance an d
Subtyping . In Proc . OOPSLA/ECOOP ' 90, Conference on Object-Oriented Programming Systems ,
Languages and Applications ; European Conference on Object-Oriented Programming, 1990 .
[4 ] Gunther Blaschek . Implementation of Objects in Modula-2 . Structured Programming, 10 :147-155 ,
1989 .
[5 ] Grady Booch . Object Oriented Design with Applications . Benjamin/Cummings, 1991 .
[ 6 ] Timothy Budd . An Introduction to Object-Oriented Programming . Addison-Wesley, 1991 .
[ 7 ] Luca Cardelli and Peter Wegner . On Understanding Types, Data Abstraction, and Polymorphism .
ACM Computing Surveys, 17(4) :471-522, December 1985 .
[ 8] William R . Cook, Walter L . Hill, and Peter S . Canning . Inheritance Is Not Subtyping . In Proc 7th.
Symposium on Principles of Programming Languages . ACM Press, January 1990 .
[ 9] Brad J . Cox . Object Oriented Programming - An Evolutionary Approach . Addison-Wesley, 1986 .
[10] 0 . J . Dahl, E . W . Dijkstra, and C . A . R . Hoare . Structured Programming . Academic Press, 1972 .
[11] Edsger W . Dijkstra . Go To Statement Considererd Harmful .
11(3) :147-148, March 1968 .
Communications of the ACM ,
[12] Daniel R . Edelson . How Objective Mechanisms Facilitate the Development of Large Software System s
in Three Programming Languages . SIGPLAN Notices, 22(9), September 1987 .
[13] Peter Grogono . Issues in the Design of an Object-Oriented Programming Language . Structure d
Programming, 12 :1–15, 1991 .
[14] Samuel P . Harbison . Modula-3 . Prentice Hall, New Jersey, 1992 .
65
[15] Joan K. Huges and Jay I. Michtom. A Structured Apporach to Programming. Prentice-Hall, 1977.
[16] Luca Cardelli and James Donahue and Lucille Glassman and Mick Jordan and Bill Kalsow and Greg
Nelson. Modula-3 Report (revised). Research Report 52, Digital Equipment Corporation, Systems
Research Center, November 1989.
[17] Bertrand Meyer. Object-oriented Software Construction. Prentice Hall, 1988.
[18] Bertrand Meyer. From Structured Programming to Object-Oriented Design: The Road to Eiffel.
Structured Programming, 1:19-39, 1989.
[19] Bertrand Meyer. Eiffel: The Language and the Environment. Prentice Hall, 1990.
[20] David E. Monarchi and Gretchen I. Puhr. A Research Typology for Object-Orented Analysis and
Design. Communications of the ACM, 35(9), 1992.
[21] D.L. Parnas. On the criteria to be used in decomposing systems into modules. Communications of
the ACM, 15(12):1053-1058, 1972.
[22] Tim Rentseh. Object Oriented Programming. SIGPLAN Notices, 17(9), September 1982.
[23] Alan Snyder. Encapsulation and Inheritance in Object-Oriented Programming Languages. In Norman Meyrowitz, editor, Proc. OOPSLA '86, Conference on Object-Oriented Programming Systems,
Languages and Applications, Portland, OR, September 1986. ACM.
[24] M. Stefik and D.G. Bobrow. Object-Oriented Programming: Themes and Variations. AI-Magazine,
6(4):40-62, 1986.
[25] Bjarne Stroustrup. The C++ Programming Language Second Edition. Addison-Wesley, Reading,
1991.
[26] Clemens A. Szyperski. Import is Not Inheritance - - Why We Need Both: Modules and Classes. In
O. Lehrmann Madsen, editor, Proc. ECOOP'92, European Conference on Object-Oriented Programming, LNCS 615, Utrecht, The Netherlands, June/July 1992. Springer.
[27] Peter Wegner. Concepts and Paradigms of Object-Oriented Programming. OOPS Messenger, 1(1),
August 1990.
[28] Peter Wegner. The Object-Oriented Classification Paradigm. In Bruce Shriver and Peter Wegner,
editors, Research Directions in Object-Oriented Programming. MIT Press, Cambridge, MA, 1991.
[29] Niclaus Wirth. Program Development by Stepwise Refinement. Communications of the ACM, 14(4),
1971.
[30] Niklaus Wirth. Systematic Programming. Prentice-Hall, 1973.
[31] Rebecca J. Wirts-Broek and Ralph E. Johnson. Surveying current Research in Object-Oriented
Design. Communications of the ACM, 33(9), 1990.
66