Encapsulation and Inheritance

in
Object-Orlented Programming Languages

Alan Snyder
Software Technology Laboratory
Hewlett-Packard Laboratories
P.O. Box 10490
Pain Alto CA 94303-0971
(415) 857-8764

the concepts of encapsulation and data abstraction, as re-

Abstract alized by most object-oriented languages. We then review
Object-oriented programming is a practical and useful pro- the concept of inheritance and demonstrate how the in-
gramming methodology that encourages modular design heritance models of popular object-oriented languages like
and software reuse. Most object-oriented programming lan- Smalltalk [Goldberg83], Flavors [Moon86], and Objective-
guages support data abstraction by preventing an object C {Cox84] fall short in their support of encapsulation. We
from being manipulated except via its defined external op- examine the requirements for full support of encapsulation
erations. In most languages, however, the introduction of with inheritance.
inheritance severely compromises the benefits of this en-
capsulation. Furthermore, the use of inheritance itself is
Object-Orlented Progranunlng
globally visible in most languages, so that changes to the
inheritance hierarchy cannot be made safely. This paper Object-oriented programming is a programming methodol-
examines the relationship between inheritance and encap- ogy based on the following key characteristics:
sulation and develops requirements for full support of en-
• Designers define new classes (or types) of objects.
capsulation with inheritance.
• Objects have operations defined on them.
• Invocations operateon multlple types ofobjects (i.e.,
Introduction. operations are generic).
Object-oriented programming is a practical and useful pro- • Class definitions share common components using
gramming methodology that encourages modular design inheritance.
and software reuse. One of its prime features is support for
data abstraction, the ability to define new types of objects In this paper, we use the following model and terminology:
whose behavior is defined abstractly, without reference to An object-oriented programming language allows the de-
signer to define new classes of objects. Each object is an
implementation details such as the data structure used to
instance of one class. An object is represented by a collec-
represent the objects.
tion of instance variables, as defined by the class. Each class
Most object-oriented languages support data abstraction defines a set of named operations that can be performed on
by preventing an object from being manipulated except via the instances of that class. Operations are implemented by
its defined external operations. Encapsulation has many procedures that can access and assign to the instance vari-
advantages in terms of improving the understandability of ables of the target object. Inheritance can be used to define
programs and facilitating program modification. Unfortu- a class in terms of one or more other classes. If a class c
nately, in most object-orlented languages, the introduction (directly) inherits from a class p, we say that p is a parent
of inheritance severely compromises encapsulation. of c and that c is a child of p. The terms ancestor and
This paper examines the issue of encapsulation and its sup- descendant are used in the obvious way. t
port in object-oriented languages. We begin by reviewing
t We avoid the traditional terms m u b d a u and superclass because these
terms are often used ambiguously to mean both direct and mdwect
inheritance.

permission to copy without fee all or pan of this material is granted provided
that the copies are not made or distributed for direct commercial edvantage,
the ACM copyright notice and the title of the publication and its date appear,
amt notice is given that copying is by permission of the Association for
Computing Machinery. To copy otherwise, or to republish, requires a fee and/
or specific permission.

© 1986 ACM 0-89791-204-7/86/0900-0038 75¢

38 OOPSLA'86 Proceedings Seplmnter lg86

Encapsulation the class are created, including any creation parameters.
In many languages, a class is itself an object, and its ex-
Encapsulation is a technique for minimizing interdependen-
ternal interface consists of a set of operations, including
t;us among separately-written modules by defining strict
operations to create instances.
external interfaces. The external interface of a module
serves as a contract between the module and its clients, To summarize, objects in most object-oriented program-
and thus between the designer of the module and other de- ruing languages (including class objects) are encapsulated
signers. If clients depend only on the external interface, the modules whose external interface consists of a set of opera-
module can be reimplemented without affecting any clients, tions; changes to the implementation of an object that pre-
so long as the new implementation supports the same (or serve the external interface do ant affect code outside the
an upward compatible) external interface. Thus, the effects class definition? If it were not for inheritance, the story
of compatible changes can be confined. would end here.
A module is encapsulated if clients are restricted by the
definition of the programming language to access the mod- Inheritance
ule only via its defined external interface. Encapsula-
tion thus assures designers that compatible changes can be Inheritance complicates the situation by introducing a new
category of client ror a class. [n addition to clients that
made safely, which facilitates program evolution and main-
simply instant;ate objects of the class and perform oper-
tenance. These benefits are especially important for large
systems and long-lived data. ations on them, there are other clients (class definitions)
that inherit from the class. To fully characterize an object-
To maximize the advantages of encapsulation, one should oriented language, we must consider what external interface
minimize the exposure of implementation details in external is provided by a class to its children. This external inter-
interfaces. A programming language supports encapsula- face is just as important as the external interface provided
tion to the degree that it allows minimal external interfaces to users of the objects, as it serves as a contract between the
to be defined and enforced) This support can be charac- class and its children, and thus limits the degree to which
terized by the kinds of changes that can safely be made to the designer can safely make changes to the class.
the implementation of a module. For example, one charac-
teristic of an object-oriented language is whether it permits Frequently, a designer will want to define different exter-
nal interfac~ for these two categories of clients. Most
a designer to define a class such that its instam:e variables
object-oriented languages respond to this need by provid-
can be renamed without affecting clients.
ing a much less restricted external interface to children of
a class, lly doing so, the advantages of encapsulation that
Data Abstraction one associates with object-oriented l a n g u a g e s are severely
weakened, as the designer of a class has less freedom to
Data abstraction is a useful form of modular programming.
make compatible changes. This issue would be less impor-
The behavior of an abstract data object is fully defined by a
tant if the use of inheritance were confined to individual
set of abstract operations defined on the object; the user of
designers or small groups of designers who design families
an object does not need to understand how these operations
of related classes. However, systems designers have found
are implemented or how the object is represented.
it useful to provide classes designed to be inherited by large
Objects in most object-oriented programming languages are numbers of classes defined by independent applications de-
abstract data objects. The e eternal interface of an object is signers (the class window in the Lisp Machine window sys-
the set of operations defined upon it. Most object-oriented tem [Weinreb81] is a good example); such designers need
languages limit external ac~.ess to an object to invoking the protection of a well-defined external interface to permit
the operations defined on the object, and thus support implementation flexibility.
encapsulation) Changes to the representation of an object
We will begin our examination of inheritance with the issue
or the implementation of its operations can be made with-
of access to inherited instance variables.
out affecting users of the object, so long as the externally-
visible behavior of the operations is unchanged.
A class definition is a module with its own external iqter- Inheriting Instance Variables
face. Minimally, this interface describes how instances of in m o s t o b j e c t - o r i c n t e d languages, tile code of a class may
directly access all the instance variables of its objects, even
= One can always improve the encapsulation support provided by a those instance variables that were defined by an ancestor
language by extending it with additioilal declarations (in tile f*,rm
of machhte readable coutmeuts, say) and writing programs to verify class. Thus, the designer of a class is allowed full access to
that clients obey these declarations. However, the elfective result the representation defined by an ancestor class.
of this approach is that a new language h ~ been defined (in a way
that happens to avoid chaughls the existing compiler); tile original This property does not change the external interface of in-
language has not become any less deficieut. dividual objects, as it is still the case that the instance
Most practical languages provide escapes front strict e,capsulation to
support debugging and the creation of programming environments. 4 In c++ [Stroustrup861, an operation performed on one object of a
For example, in Smailtalk the operations instVarAt: and t n s t - class cat; access the ifiternals of other objects of the class; time, the
VarAt:put: allow access (by numeric offset) to any named instance set of objects of a class is an encapsulated module rather than each
variable of any object [Goldberg83, p. 247[. Because these ettcapes individual object. W e ignore thi~ disti,ction in this paper ar it does
are not normally used m ordinary progralnutingj we ignore them ill not affect our analysis.
this analysis.

September 1986 OOPSLA '86 Proceedings 39

variables of an object are accessible only to operations de- resolved the same way: Syntactic abbreviations allow the
fined on that object. However, it does change the external inheriting class to use ordinary variable reference syntax to
interface of the class (as seen by its descendants), which invoke these operations [Snyder85a]/ Inline substitution
now (implicitly) includes the instance variables. avoids the overhead of invoking a procedure (at the cost of
Permitting access to instance variables defined by ances- requiring recompilation of the client if an ancestor class is
tor classes compromises the encapsulation characteristics incompatibly changed).
stated above: Because the instance variables are accessible T h e most serious objection to this solution is that it requires
to clients of the class, they are (implicitly) part of the con- the cooperation of the designer of the ancestor class that
tract between the designer of the class and the designers of defines the instance variable (as well as the designers of
descendant classes. Thus, the freedom of the designer to all intervening ancestors), since no access to an inherited
change the implementation of a class is reduced. The de- instance variable is possible unless appropriate operations
signer can no longer safely rename, remove, or reinterpret have been provided. We claim this is as it should be. If you
an instance variable without the risk of adversely affecting (as designer of a class) need access to an inherited instance
descendant classes that depend on that instance variable. variable and the appropriate operations are not defined, the
In summary, permitting direct access to inherited instance correct thing to do is to negotiate with the designer(s) of
variables weakens one of the major benefits of object- the ancestor class(es) to provide those operations?
oriented programming, the freedom of the designer to One problem with this scenario is that the instance vari-
change the representation of a class without impacting its able operations defined on a class for the benefit of its de-
clients. scendants may not necessarily be appropriate for users of
instances of the class, yet they are publically available. A
convenient solution (provided by Trellis/Owl) is to declare
Accessing Inherited Variables Safely that some operations are available only for direct invoca-
To preserve the full benefits of encapsulation, the external tion (on s e l f ) by descendant classes, but are not part of
interfaces of a class definition should not include instance the external interface of objects of the class. This notion
variables. Instance variables are protected from direct ac- is a generalization of the ~private operations" provided by
cess by users of an object by requiring the use of operations various languages, including Trellis/Owl and C**. It gives
to access instance variables. The same technique can be the designer fine-grained control over the external interfaces
used to prevent direct access by descendant classes. provided to the two categories of clients of a class.
Additional language support is required to permit instance If instance variables are not part of the external interface
variable access operations to be used effectively by descen- of a parent class, then it is not proper to merge inherited
dant classes. Ordinary operation invocation on s e l f s is instance variables with instance variables defined locally in
inadequate, as it may invoke the wrong operation (if the op- a class (as is done by Flavors). Clearly, if a local instance
eration is redefined by the class or one of its descendants). variable and an inherited instance variable with the same
Instead, a way is needed to directly invoke (on s e l f ) an op- name wind up as a single instance variable, then changing
eration as defined by a parent class. Smalltalk provides a the name of the instance variable in the parent is likely to
mechanism in the context of single inheritance: the pseudo- change the behavior of the child class. It is also inappropri-
variable s u p e r . Performing an operation on s u p e r is like ate to signal an error if a class defines an instance variable
performing an operation on s e l f , except that the search for with the same name as an inherited instance variable (as
the operation to invoke starts with the parent of the class is done by Smalltaik), as changing the name of an instance
in which the invocation appears, instead of with the class of variable could make a descendant class illegal. Similar ob-
s e l f . Equivalent features using compound names (parent jections apply to merging instance variables defined by mul-
and operation) to specify the desired operation are provided tiple parents (as is done by Flavors), or signalling an error
by CommonObjects [SnydergSa], Trellis/Owl [Schaffert86}, if multiple parents define instance variables with the same
extended Smalltalk ° [Borning82 I, and C** (Stroustrup86]. name (as is done by extended Smalltalk).
Because the search for the proper operation starts at a stat-
ically known class, invoking an operation in this manner
can be more efficient than normal operation invocation; in The Visibility of Inheritance
some implementations, no run-time lookup is required. A deeper issue raised by inheritance is whether or not the
There are several possible objections to using operations use of inheritance itself should be part of the external in-
to access inherited instance variables. Most of these objec- terface (of the class or the objects). In other words, should
tions also apply to the ordinary case of using operations to
access the instance variables of an object, and they can be 7 This option is u special case of u general construct which we call
pseudo variables [Snyder88b]. A pseudo variable looks like an ordi-
nary lexicnl variable, but the effect of referencing or assigning to the
s In Smalltalk a n d m a n y of its derivatives, m..l_f is used within an
variable is to execute arbitrary (possibly user-specified) code.
o p e r a t i o n to refer to the object t h a t the operation is being performed e A software development environment might allow you to circumvent
on. N a m e s used in o t h e r languages for the same purpose include me this restriction, say by temporarily defining those operations yourself.
and t h i s , However, if you seriously intend to leverage off someone else's code,
e We use the t e r m "extended Smalltalk ~ to refer to the multiple inher-
such negotiation is essential.
itance extension to Smalltalk defined by Borning and Ingalb.

40 OOPSLA '86 Proceedings September1986

clients of a class (necessarily) be able to tell whether or not advantage of static type checking (in languages like Trel-
a class is defined using inheritance? lis/Owl and C**) and can lead to unnecessary name con-
If the use of inheritance is part of the external interface, flicts involving the ~excluded" operations.
then changes to a class definition's use of inheritance may Even if a child excludes an inherited operation from its
affect client code. For example, consider a class that is external interface, it is useful to be able to invoke the oper-
defined using inheritance. Suppose the designer of that ation (on s e l f ) within the child. Ordinary operation invo-
class decides that the same behavior can be implemented cation cannot be used, because the operation is not defined
more efficiently by writing a completely new implementa- on instances of the child. However, as described above in
tion, without using the previously inherited class. If the the section on accessing inherited instance variables, sev-
previous use of inheritance was visible to clients, then this eral languages (including CommonObjects) provide the re-
reimplementation may require changes to the clients. The quired ability to directly invoke an operation defined by a
ability to safely make changes to the inheritance hierarchy parent class.
is essential to support the evolution of large systems and
long-lived data.
Subtyping
This issue raises the fundamental question of the purpose
of inheritance. One can view inheritance as a private de- One way in which inheritance can appear in the external
cision of the designer to "reuse" code because it is useful interface of a class is subtyping, the rules by which objects
to do so; it should be possible to easily change such a de- of one type (class) are determined to be acceptable in con-
cision. Alternatively, one can view inheritance as making texts expecting another type (class). In statically-typed
a public declaration that objects of the child class obey languages like Trellis/Owl, Simula IDah166], and C**, sub-
the semantics of the parent class, so that the child class is typing rules are of critical importance because they deter-
merely specializing or relining the parent class. This ques- mine the legality of programs. In dynamically-typed lan-
tion is addressed in the context of knowledge representation guages like Common Lisp [Steele84}, subtyping rules affect
in [Brachman85]. the results of type predicatt',.

Our position is that being able to use inheritance without Many object-oriented languages relate subtyping and in-
making a public commitment to it in the external inter- heritance. For example, in Trellls/Owl, Simula, and C*÷
face of a class is valuable, and we will analyze how exist- a class x is a subtype of a class y if and only if x is a de-
ing object-oriented languages support this option. We will scendant of y. If the designer should reimplement class x
begin by considering only the single inheritance case, i.e., so that it inherits from class z instead of ¥, client programs
where the inheriting class (the child) directly inherits from that assume x is a subtype of y would no longer be legal,
a single class (the parent). Multiple inheritance introduces e v e n if the intended external interface of x {the operations)
additional problems and will be discussed below. is unchanged. Thus, the use of inheritance is exposed via
the subtyping rules. °
To avoid this problem, Subtyping should not be tied to in-
Excluding Operations heritance. Instead, subtyping should be based on the be-
Most object-oriented languages promote inheritance as a havior of objects. If instances of class x meet the external
technique for specialization and do not permit a class to interface of class y, then x should be a subtype of y. The
=exclude ~ an inherited operation from its own external in- example above demonstrates that the implementation hi-
terface. However, if inheritance is viewed as an implemen- erarchy need not be the same as the type hierarchy (as
tation technique, then excluding operations is both reason- defined by object behavior) !Canning85]. In tha~ example,
able and useful. stack inherits from deque but is not a subtype of deque,
For example, consider the abstractions stack and deque, and deque is a subtype of stack but does not inherit from
where a stack is a queue that permits elements to be added stack.
or removed from one end, and a deque is a queue that per- Behavioral subtyping cannot be deduced without formal
mits elements to be added or removed from either end. The semantic specifications of behavior. Lacking such specifi-
external interface of a deque is a superset of the external cations, one can deduce subtyping based solely on syntac-
interface of a stack: a deque has two additional operations tic external interfaces (i.e., the names of the operations)
for adding and removing elements from the "back end". [Cardelli84]. Alternatively (or in addition), one can allow
The simplest way to implement these two abstractions (at the designer of a class to specify which other classes it is a
least for prototyping purposes) is to define the class stack subtype of. The default may be that a class is a subtype of
to inherit from the class deque, and exclude the extra op- each of its parents. However, as demonstrated by the ex-
erations. Stack inherits the implementation of deque, but ample, the designer must be able to specify that the class is
is not a specialization of deque, as it does not provide all not a subtype of a parent or that the class is a subtype of an
the deque operations. unrelated cla~s (not its parent). The first case arises when

The ability for a class to exclude operations defined by its

0 It should be noted tha~ althuugh equating subtypiug of cla~ses with
parents is provided in CommonObjects. Of course, this ef- inheritance entails = loss of flexibility, it h=s signiEcant implementa-
fect can be achieved in any object-oriented language simply tion advantages in statlcally-typed languages like those mentioaed,
where the coet of performing aa operation involves at most aei exera
by redefining the operation in the child class to signal an level of indu-ection.
error when invoked. Doing so, however, fails to take full

September 1986 OOPSLA'86 Proceedings 41

the behavior of the objects is incompatible with the inter-
face of parent objects. The second case arises when the Z
class is supporting the external interface of another class
without sharing its implementation.
yl
/\ y2
CommonObjects, an object-oriented extension to Common
Lisp, is an example of a language that allows the designer
to specify the type hierarchy independently of the inheri-
-,,/ X
tance hierarchy. In Common Lisp, type checking is defined
in terms of a predicate typep that takes two arguments,
an object and a type specification, and returns true if and F i g u r e 1: E x a m p l e of m u l t i p l e I n h e r i t a n c e .
only if the object is a member of the specified type. Com-
monObjects classes are integrated into the Common Lisp ancestor. As a result, in the~e languages, the names of an-
type system such that if the object given to typep is an in- cestor classes are unavoidably part of the external interface
stance of a class and the type specification is a class name,
of a class.
then the : typep operation i:; performed on the object (with
the type specification as the argument) to determine the
result of typep. The desig,er of a class can write an ar- Multiple I n h e r i t a n c e
bitrary predicate for this operation, although a default is Multiple inheritance means that a class can have more than
provided.'° one parent. One can view a class (call it the root class) as
The following operations would be used in the above exam- forming the root of a directed (acyclic) graph, which we will
ple: call an inheritance graph, where each class is a node and
there is an arc from each class to each of its parents. Figure
(define-method ( s t a c k :typep) ( t h e - t y p e ) 1 shows an inheritance graph with multiple inheritance. In
(equal t h e - t y p e ' s t a c k ) ) this example, class x is the root class. Class x inherits from
classes y l and y2, and classes y l and y2 both inherit from
( d e f i n e - m e t h o d (deque :typep) ( t h e - t y p e ) class Z.
(or (equal t h e - t y p e 'dequo)
(equal t h e - t y p e ' s t a c k ) There are two strategies in common use for dealing with
)) multiple inheritance. The first strategy attempts to deal
with the inheritance graph directly. The second strategy
This primitive mechanism is sufficient, but is neither con- first flattens the graph into a linear chain, and then deals
venient nor reliable. A better solution would explicitly rep- with that chain using the rules for single inheritance.
resent subtyping relationships and ensure transitivity.
G r a p h - O r i e n t e d Solutions
A t t r i b u t e Visibility Trellis/Owl and extended Smaiitalk are examples of object-
If the use of inheritance is not part of the external interface oriented languages whose semantics model the inheritance
of a class, then clients of the class may not directly refer to graph directly. In these languages, operations are inherited
ancestors of the class. Specifically, a class may refer to its along the inheritance graph until redefined in a class. If
parents, but not its more distant ancestors. a class inherits operations with the same name from more
than one parent, the conflict must be resolved in some way.
As mentioned above, it is useful for a class to be able to
One way is to redefine the operation in the child class; the
invoke an operation defined by a parent. In most languages new definition can invoke the operations defined by the par-
that support this feature, the desired operation is specified ent classes. To invoke all definitions of an operation in the
by a compound name consisting of the name of the par- inheritance graph (e.g., all d i s p l a y operations), each class
ent class and the name of the operation. This solution is could define an operation that invokes the operation on
sufficient: To access an operation of a more distant ances- each of its parents and then performs any local computa-
tor without violating encapsulation, that operation must tion, resulting in a depth-first traversal of the inheritance
be passed down via all intervening ancestors including at graph. Extended Smalltalk provides a convenient syntax
least one parent. Trellis/Owl and extended Smalltalk allow for invoking an operation on each parent of a class.
a class to directly name an operation of a non-immediate
In these languages, the interesting issues arise when the
graph is not a tree, i.e, when a single class is reachable
zo SmaUtall, defines an operation i a K i u d O f : on all objects t h a t testa from the root class by multiple paths (as in Figure 1). Trel-
w h e t h e r the object is a n instance of a ciM8 or one of its descendanta;
however, it is not clear t h a t this operation can usefully be redefined. lis/Owl and extended Smalltalk adopt similar solutions for
resolving the conflict when a class attempts to inherit an
operation from more than one parent: It is an error 1~ if a
class inherits operations with the same name from two or

II 'IYellis/Owlsignalsan error at compilationtime; extended SmaHtalk

creates an operationfor the class that signalsan error when invoked.

42 OOPSLA '86 Proceedings September 1986

 Now suppose the designer of class y2 decides to reimple-
Z ment y2 to inherit from z in a manner that preserves the

? external behavior of objects of class y2; assume that class

y2 will either inherit o from z or will revise its definition
of o to invoke o as defined by z. The operation o on class
yl y2

\/ X
x will now have the effect of invoking the operation o on
class s twice, on the same set of instance variables. If o on z
has side-effects, the result might not be acceptable. Thus,
in this example, a change to the use of inheritance by a
F i g u r e 2: A l t e r i n g t h e i n h e r i t a n c e s t r u c t u r e . class (y2) has broken one of its clients (x), even though
its operations have the same external behavior; the use of
more parents, but only if the operations are actually differ- inheritance is therefore (implicitly) part of the external in-
ent. In other words, if the same operation (from the same terface of the class y2.
class) is inherited by a class via different paths through the
inheritance graph, it is not an error.
Linear Solutions
This same-operation exception is motivated by convenience,
The second strategy for dealing with multiple inheritance
as operation conflicts are inevitable when there is merging
is to first flatten the inheritance graph to a linear chain,
in the inheritance graph. Although this exception may at
without duplicates, and then treat the result as single in-
first glance seem innocuous, it forces the use of inheritance
heritance. This strategy is used by Flavors (as recently
to be part of the external interface.
revised) IMoon86] and CommonLoops [Bobrow86 I. These
Consider further the example shown in Figure I. If an op- languages use similar algorithms for creating a total order-
eration o is defined (only) by the class z, it will be inherited ing that preserves the ordering along each path through the
by yl and y2 and then by x (with no error). Now suppose inheritance graph (a class never appears after one of its an-
the class y2 is relmplemented so that it no longer inherits cestors). Flavors attempts as well to preserve the relative
from s (see Figure 2) but still supports the same behavior. ordering of the parents of a class (the first parent of a class
Class x will now be in error, because it is inheriting two dif- never appears after the second, etc.); an error is signalled
t'ezent operations named o, one from class z via class yl and if no total ordering exists that satisfies all such constraints.
one from class y2. (The operations are different yet have
While the relative ordering of a class and its ancestors is
equivalent behavior on objects of their respective classes.)
preserved in the total ordering, unrelated classes can be
Thus, the change to class y2 to stop inheriting from z was
visible to class x, a client of class y2. The external inter-
face of y2 was therefore changed, even though the external Z

interface of its instances remains unchanged (the instances

have the same externally-visible behavior). Ty2
To prevent the use of inheritance from necessarily becoming
part of the external interface of a class, one must abandon
the convenient same-operation exception to the rule regard-
?yt
ing operation conflict. An alternative conflict resolution
technique that avoids this problem is to select the opera-
tion from the *first" parent that defines one (based on the
textual order in which the parents are named); this alter-
TX

native is undesirable because it fails to warn the designer

about unintentional conflicts. F i g u r e 3: L i n e a r l z e d m u l t i p l e i n h e r i t a n c e .
Another attribute of the graph-oriented solution is that
only one set of instance variables is defined for any ancestor inserted between a class and its parent. For example, the
class, regardless of the number of paths by which the class inheritance graph shown in Figure 1 would be transformed
can be reached in the inheritance graph. For example, in into the chain shown in Figure 3. Note that the class y2
Figure 1, an instance of x contains one of each instance now appears between class y l and its parent class z. Thus,
variable defined by z, not two although these languages t:'eat the computed inheritance
chain as single inheritance, the computed inheritance chain
While this result is usually desirable, it introduces potential
has the unusual property that the ~efl'ective parent" of a
problems. For example, using a depth-first traversai (as
class c may be a class of which the designer of class c has
described above) on an inheritance graph with merging will
absolutely no knowledge.
result in some operations being invoked more than once on
the same set of instance variables. As a result, a designer One problem with this solution is that in the case of op-
cannot change the use of inheritance within a class without eration conflicts (two or more parents defining the same
the danger of breaking some descendant class. operation), one operation will be selected even if there is
no clearly "best" choice. Consider the above example: If
Consider the structure shown in Figure 2. Suppose the op- operation o is defined only by classes yl and y2, then class
eration o is defined by classes z, y2, and x, where the defi-
nition of o in class x invokes operation o on both parents.

September 1986 OOPSLA '86 Proceedings 43

 x will inherit the operation defined by class yl. This selec- The tree solution used by CommonObjects avoids exposing
tion assumes that the ordering of parents in a class defini- the use of inheritance, but radically changes the seman-
tion is significant. Although such conflicts are likely to be tics of inheritance graphs with shared nodes. Applications
unintentional, no warning is given. in other languages that use shared ancestors would almost
Another problem involves the ability of a class to reliably certainly have to be redesigned in CommonObjects (and
communicate with its ~real* parents. CommonLoops al- vice versa). Shared ancestors typically arise when inher-
lows a class to invoke its "effective parent" (its parent in iting multiple "base~ classes, where a ~base ~ class is one
the computed inheritance chain) using a notation similar to that defines a "complete" set of operations and is generally
super in Smalltalk. Flavors provides a declarative mecha- designed to be instantiated. An alternative is to inherit a
nism called method combination that is essentially equiv- single "base ~ class and one or more Umixin~ classes, where
alent. These mechanisms avoid the problem of uninten- a ~mixin" class [Weinreb81] defines a set of operations re-
tional multiple invocations of operations that can occur us- lated to one particular feature and is designed only to be
ing graph-oriented solutions. However, these mechanisms inherited from ("mixed into~ a class). Using this strategy,
make it difficult for a class to reliably set up private com- designers will be encouraged to create more, and more gen-
munication with a parent, given the interleaving of classes eral, "mixin" classes. Further experimentation is needed to
that can occur when the inheritance chain is computed. determine the practicality of this alternative programming
style.
In the above example, suppose that class yl wants to com-
municate privately with its parent z; specifically, it wants Inheritance in ThingLah [BorningSl] uses a modified tree
to invoke (public) operations defined by z without being af- solution: it differs from CommonObjects in two major ways:
fected by redefinitions of those operations by other classes. in ThingLab, each parent (called a part) is an object in its
This kind of private communication is easily arranged in own right, and the ThingLab merge capability can explic-
the graph-oriented languages (Trellis/Owl and extended itly induce merging in the inheritance hierarchy.
Smalltalk) by directly naming the operations of z. How-
ever, using super or its equivalent, class yl can directly
Summary
invoke only operations of its "effective parent ~, which in
this case is y2; if y2 happened to redefine the operation in We have identified two areas where most object-oriented
question, the "wrong* operation (from y l ' s point of view) languages are deficient in their support for encapsulation.
would be invoked. This example demonstrates that to cor- One area is the encapsulation of instance variables, a sig-
rectly use yl as a parent, one must understand details of nificant feature of most object-oriented languages. Many
its internal design regarding its use of its parent z. popular object-oriented languages (e.g., Smalltaik, Flavors,
and Objective-C) allow free access to inherited instance
Unlike the graph-oriented languages, neither Common-
variables by descendant classes, thus denying the designer
Loops nor Flavors s,llows a class to designate an operation
the freedom to compatibly change the representation of a
by the name of the defining parent. Adding this feature class without affecting clients. It is encouraging that sev-
would allow one to simulate the semantics of the graph- eral newer languages (CommonObjects~ Trellis/Owl, and
oriented languages. However, its use would be error-prone,
C+*) correct this deficiency by restricting access to inher-
as mixed use of the two different styles (linear or graph)
ited instance variables. Where access to inherited instance
would probably produce undesirable results.
variables is needed, it should be provided in the form of
operations. Language support is needed to permit classes
Tree Solutions to directly invoke parent operations (on s e l f ) and to per-
mit such operations to be made available in this manner
We are exploring in CommonObjects [Snyder85a] a third but not via ordinary operation invocation. Furthermore,
strategy for handling multiple inheritance that avoids the the implicit by-name merging of instance variables defined
problems of the graph-oriented and linear solutions. Like in separate classes is inconsistent with the goals of encap-
the graph-oriented solutions of Trellis/Owl and extended sulation.
Smalltalk, the semantics of CommonObjects models the in-
heritance graph. However, there are two key differences: The other area is the visibility of inheritance itself. Inher-
(1) An attempt to inherit an operation from more than one itance is a useful mechanism for reusing code; the decision
parent is always an error, regardless of the source(s) of the by the designer to use inheritance for this purpose should
operation. This change plugs the Uleak* described above. be private and easily changed. To permit the use of in-
(2) The inheritance graph is converted into a tree by du- heritance to be private, a class must be able to exclude
plicating nodes. In other words, each parent of each class operations defined on its parents. A class must not refer to
defines a completely separate set of inherited instance vari- ancestors other than its parents. A language cannot define
ables; if a class is reachable by multiple paths through the a subtyping relation based solely on inheritance. Conflicts
inheritance graph, a separate set of instance variables will in operation inheritance between multiple parents must be
be created for each such path. For example, in Figure 1, an reported regardless of the source(s) of the operation(s).
instance of x contains two of each instance variable defined The two models of multiple inheritance in common use both
by z. This change avoids situations where ail operation is require knowledge about the use of inheritance by a class
accidentally invoked multiple times on the same set of in- to understand how to correctly inherit that class. Com-
stance variables or where two classes conflict in their use of monObjects provides an alternative form of multiple inher-
an inherited class. itance that supports encapsulated class definitions whose

44 OOPSLA'86 Proceedings Sep~mber1986

external interface is fully defined by a set of operations; References
further experimentation is needed to evaluate and refine
this programming style. [Bobrow86] Danny Bobrow, et ILl. CommonLoops: Merging Common
Lisp mad Object-Oriented Programming. Proc. ACM Conference
The challenge for language designers is to provide the on Object-Oriented Systems, Languages, and Applications. Port-
means by which the designer of a class can express an in- land, Oregon, Sept. 1986.
terface to inheriting clients that reveals the minimum in- [Borning81] Alan Borni,g. The Prograntming Language Aspects of
formation needed to use the class correctly. ThingLab, a Constraint-Oriented Simulation Laboratory. ACM
~anaactions on Programming Languages and Systems 3:4 (Oct.
1981), 353-387.
[Borning82] Alan Borning and Daniel lngalls. Multiple Inheritance i,
Smalltalk-80. Proc. AAAi 1982, 234-237.
[Brachman85] Ronald J. Rrachma~,. "! Lied about the Trees" - Or, De-
faults and Definitions in Knowledge Representation. AI Magazine
e:3 (F~ zgss), 8o-93.
[Canning85] Peter Canning. Personal communic~tio..
[Cardelli841 Luca Cardelli. The Semantics of Multiple ],heritance.
Proceadingn o[ the Conference on the Semantics of Datatypes.
Springer-Verlag Lecture Notes in Computer Scie.ce, June 1984,
51-66.
[Cox84] Brad Cox. Message/Object Programming: An Evolutionary
Change in Programming Technology. IEEE Software 1:1 (Ja..
1984), 50-61.
[DahlO61 O.-J. Dahl and K. Nygaard. Simula - An Algol-baaed Simu-
lation Language. Comm. A C M 9:9 (Sept. 1966), 671-678.
[Goldbecg83J Adele Goldberg and David Robson. Smalhalk.80: The
Language and its h,plementation. Addison-Wesley, Reading,
Mauachusetts, 1983.
[Moonae]David A. Moon. Object-Oriented Progr~umlJiag with Flavors.
Proc. ACM Conference on Object-Oriented Systems, Languages,
and Applications. Portland, Oregon, Sept. 1986.
[Scliaffert86} Craig SchaHert, st. al. An lotrodnction to Trellis/Owl.
Proc. ACM Conference on Object-Oriented Systems, Lauguages,
and Applications. Portland, Oregon, Sept. 1986.
[Snyder85a] Alan Snyder. Object-Oriented Progrannnmg for Com-
mon Lisp. Report ATC-85-1, Software Technology Laboratory,
Hewlett-P~ckard Laboratories, P&io Alto, California, 1985.
[Snyder85bJ Alan Snyder, Michael Creech, auzd James Kempf. A Com-
mon Lisp Objects Implementation Kernel. Report STL-85.08,
Software Technology Laboratory, Hewlett-P~chrd Laboratories,
Palo Alto, California, 1985.
[Steele84J Guy L. Steele, Jr. Common Lisp - The Language. Digital
Press, 1984.
[Stroustrup86] Bjarne Stroustrup. The C+* Programming Language.
Addison-Wesley, Reading, MLssachusetts, 1986.
{Weinreb81} DaJtiel Weiureb and David Moo.. Lisp Machine Manual
Symbolics, Inc., 1981.

September1986 OOPSLA '86 Proceedings 45