rusuur¢lt summaries and

experience reports

Meilir Page-Jones

Comparing Techniques by
Means of Encapsulation and
¢onnascence
oday the object-oriented approach to software development is at the height of
fashion. As such, it threatens to replace the structured approach which was the
staple development approach of the 1970s and 1980s. • • • • • • • • • •

Both approaches have their gen- teraction between researchers of of encapsulation level-1 or "L 1"
esis in programming. Structured the two approaches. Consequently, encapsulation as seen in Figure 1.
programming began in the late the two fields tended to develop Object-oriented design encapsu-
1960s and is usually traced to work- different vocabularies and differ- lates units called classes.1 T h e struc-
ers such as Dijkstra [4]. Although ent foci of utilization. These appar- ture of a class is more complex than
object orientation is a river with ent differences have tended to ob- that of the structured-design mod-
many tributaries, the source of ob- scure some o f the similarities ule, since a class is a template or
ject-oriented programming is often between the structured approach descriptor representing a set o f
traced--inter alia--to the late and the object-oriented approach. modules (more often called methods)
1960s and the Simula language or On the other hand, the two ap- packaged around an internal struc-
to the Smalltalk work o f Alan Kay proaches are n o t - - a s some people ture that will hold the state of each
and others at Xerox PARC, circa would imply--simply isomorphs object belonging to the class. This
1970 [5, 6]. with disparate terminology. There structure is the set of internal vari-
Therefore, the structured ap- are some deep structural distinc- ables. I will term this type o f encap-
proach rapidly grew into design tions between them. sulation "L2." As Figure 2 indicates,
and analysis techniques. Indeed, In this article, I discuss the simi- L2 encapsulation includes L1
almost contemporaneously with the larities and differences between the within it, because the methods o f a
inception of structured program- structured and object-oriented class are structurally similar to the
ming, Larry Constantine and oth- approaches to software design by modules o f structured design. (In-
ers were establishing the founda- means o f two principles: encapsula- cidentally, L0 encapsulation would
tions of structured design [2]. tion and connascence. I conclude be null encapsulation, in which the
T h r o u g h o u t the 1970s, workers by suggesting experiments involv- highest-level construct would be the
such as Doug Ross [11] and Tom ing connascence, the use of tools to humble line of procedural code or
DeMarco [3] were developing a mediate its effects and a set of steps elementary variable.)
technique that came to be known as necessary to define any new design Structured design offers two cri-
structured analysis. paradigm. teria for evaluating the quality of
Structured programming saw its encapsulation resulting from a
initial rise in popularity in the early Encapsulation and given partitioning into modules.
1970s; structured design grew in Connascence These criteria are: coupling, which
popularity in the mid-1970s and Both the structured and object- measures the binding between code
structured analysis gained many oriented approach rely on encapsu- elements that are found in distinct
adherents in the late 1970s. By con- l a t i o n - t h e technique by which a modules; and cohesion, which mea-
trast, object-oriented programming set o f software components is ag- sures the binding between code ele-
was a relative curiosity until the gregated into a structure that can ments that are found in the same
early 1980s. Object-oriented design be treated as a unit from an exter- module. T h e ideal of structured
and object-oriented analysis made nal point of view. design is to minimize the coupling
their first significant appearances Structured design encapsulates of a system's design and to maxi-
in the late 1980s [1]. lines of code into procedural units
During most of the two decades that Constantine called modules. ]Objects are the structurally equivalent con-
o f the coexistence of the structured Examples in traditional languages structs that are spawned dynamically d u r i n g
system execution. In some implementations
and the object-oriented ap- include procedures, subroutines the class and the object are degenerately iden-
proaches, there has been little in- and functions. I will term this type tical.

COMMUNICATIONS OF THE ACM/Septernber 1992/Vol.35, No.9 147

 research suntmerles ond
experience reports

T h e ideals o f low coupling and

MODULE //INVOCATION high cohesion now generalize be-
"~ SYMBOL yond structured design a n d yield a
statement that is applicable to ob-
ject-oriented design (or i n d e e d to
INTERNAL. / ~ + any future design p a r a d i g m with
LINES M1 MODULENAME
OFCODE
]---- partitioning, encapsulation a n d vis-
ibility rules): Eliminate any unneces-
sary connascence and then minimize
connascence across encapsulation
boundaries by maximizing connascence
within encapsulation boundaries.
CLASS . CLASSNAME O n e prediction of connascence,
as applied specifically to object-
METHOD " ~ , / ~ ~ - - - - - - - ' ~ x METHOD oriented design, relates to the use
o f inheritance. Some designers
allow a class to make use o f both
externally visible a n d internally vis-
ible c o m p o n e n t s o f a superclass.
INTERNAL~ - ~ meth12 [ meth14 I ~ " (The latter in Smalltalk, for exam-
ple, might be the explicit use in a
subclass o f certain instance vari-
l I ~EV~OQ( ables o f a superclass.) This creates a
great deal o f connascence across
INTERNALSTATE major (class) encapsulation b o u n d -
aries.
F i g u r e I . L1 Encapsulation This use o f inheritance implies
! say that two elements o f soft- that the maintainer o f classes (C 11,
Plguwe 2. L2 Encapsulation ware are connascent if they are C12, etc.) that inherit from C1
"born together" in the sense that would need to stay aware o f any
they somehow share the same des- changes to the internal design o f
mize the cohesion o f the de,;ign. tiny. More explicitly, I define two C1. T h e r e f o r e , C l ' s maintainer
As we saw indicated earlier, the software elements A a n d B to be could create disastrous results in
structures o f object-oriented design connascent if there is at least one descendant classes even t h r o u g h an
are m o r e complex than those o f change that could be m a d e to A that innocuous name-change to an in-
structured design. Consequently, would necessitate a change to B in ternal variable of CI.
there are potentially m o r e criteria o r d e r to preserve overall correct- T h e r e f o r e , connascence tells us
for evaluating object-oriented de- ness. that inheritance by a subclass from
sign quality. For example, in addi- As a very simple example, let us a superclass should be restricted to
tion to the cohesion o f a m e t h o d in take A to be the line declaring: only those features o f the su-
terms o f the lines o f code it con- int i; perclass that are already externally
and B to be the assignment: visible. Better yet, the notion o f
tains, we could talk about the co-
hesion o f a class in terms o f the i:=7; inheriting abstract behavior should
T h e r e are at least two examples be divorced f r o m the notion o f in-
methods that are d e f i n e d on it.
F u r t h e r m o r e , we could talk about o f connascence between A and B. heriting the internal implementa-
coupling between classes, or be- For instance, in the (unlikely) event tion o f such behavior. (See [10] for
tween methods o f the same class or that A were changed to c h a r i; then a f u r t h e r discussion o f this point.)
between methods o f different B would certainly have to be A n o t h e r object-oriented design
classes. changed, too. This is connascence of prediction o f connascence recom-
type. Also, i f A were c h a n g e d to i n t j ; mends foregoing the use o f the
I n o r d e r to discuss the quality o f
an object-oriented design, we could t h e n B should be changed t o j := 7;. C + + "friend" c o n s t r u c t - - a con-
invent new terms to a u g m e n t those This is c o n n a s c e n c e o f name. struct that blatantly promotes con-
o f coupling and cohesion, which zI chose the word "connascence" from the nascence across encapsulation
Latin roots meaning "born together." It is ety-
would give labels to such criteria. mologically close to the French "connais-
boundaries. (One might say: "With
However, to do so would be to sance" meaning knowledge, awareness or friends like that, who needs ene-
overlook a chance to generalize consciousness. Although I'm blamed for coin- mies!") T h e a r g u m e n t for this de-
ing the word, it can be found in Chambers
coupling and cohesion into the sin- Twentieth Century Dictionary (W&R Cham- sign r e c o m m e n d a t i o n is similar to
gle measure o f connascence. 2 bers Ltd., London). this a r g u m e n t .

~48 September 1992/Vol.35,No.9/COMMUNiCATIONSOFTHE ACM

 resenrch summaries und
experience reports

Here we see two forms of con-

nascence: name and type. Other f .....

forms include the following: C1

• Value, which indicates that two
software elements must contain the
same absolute values.
• Position, which refers to the spe-
cific location of two software ele-
ments in the overall code structure.
Examples might be: the positional
correspondence of actual and for-
mal parameters; and the colocation Cll C12
of procedural lines that are meant
to execute in sequence.
• Algorithm, which means that two
software elements must agree on
some c o m m o n algorithm for their
correct execution.
• Meaning, which implies that two
software elements must be defined
to have identical semantic (rather
than merely syntactic) structure. Clll Cl12
These forms of connascence are
generic, in the sense that they could
be defined in almost any design
paradigm. It is possible, however,
to define other forms of connas-
cence for particular paradigms.
For example, in the data diction-
ary of classic structured analysis (as
defined in [3], for example) we
have a variation on the connascence 01
of type, even though there is no [ meth21 [ 03 I meth 31 I
explicit m e n t i o n of type. Say there I I I I
are two entries: current-customer and
potential-customer. Assume that a
user change, such as adding a field
for a fax machine n u m b e r , applies
to data-dictionary entries for all
kinds of customers. T h u s there is a I I
connascence between each of cur- I I'" ....... O, [ meth x
rent-customer and potential-customer I I I I
a n d the "phantom type" CUS-
TOMER.
This problem has always made
changing a classic SA data diction- cence between current-customer, and F i g u r e 3. The class Inheritance hlerar-
ary a precarious activity, resulting the type C U S T O M E R would no chy under C1
in many inconsistent entries. It longer exist. Or, to be precise, it F i g u r e 4. The message 03.meth31 (ol)
remains a problem even in c u r r e n t would be localized at the single ShOWn in UON
SA CASE tools that lack an explicit point current-customer and would
notion of type. (Incidentally, the cease to be a practical problem.) F i g u r e s. The message
ol .methx( ........... )
reason that I introduced two kinds I n object orientation we might
of customer in this example was have the following:
that if there were only one k i n d - - of a type in object-oriented design.
e.g., current-customer--that one • Class membership, which is effec- • Class variables, that is the variables
would serve as a surrogate for the tively analogous to type, since a shared by all objects instantiated
type CUSTOMER. T h e connas- class represents an implementation from the same class.

COMMUNICATIONS OF THE ACM/September 1992/Vol.35, No.9 149

 roseorch $Ul~lma~iels and
exporleRce r opor/~s

• An o d d kind o f connascence de- methx). T h e r e is thus a connascence However, to be fair to the concept
rived from polymorphism, which of polymorphism between meth31 of p o l y m o r p h i s m - - a n d object ori-
can be illustrated by the following a n d the class hierarchy u n d e r C1. entation in g e n e r a l - - i t is true that
example: Assume a hierarchy o f T h e nature of the p r o b l e m could be p o l y m o r p h i s m eliminates o t h e r
classes and subclasses, C1, C 1 l, m o d i f i e d - - i f not exactly s o l v e d - - i n forms o f connascence that lead to
C12, C l l l , C l 1 2 , ..., as shown in the following ways: many code modifications when, say,
Figure 3. a new subclass is introduced.
1. Return to the situation wherein
Assume f u r t h e r that a m e t h o d
methx is defined on all classes
meth21 o f an object o2, of class C2, Conclusion
u n d e r C1. While this is a g o o d de-
sends a message to an object o3, o f F u r t h e r research is n e e d e d into the
sign p r a c t i c e - - i t aligns the subclass
class C3. This message passes as one forms o f connascence that apply to
hierarchy m o r e closely to a subtype
o f its p a r a m e t e r s an object o l , o f modern software-design para-
h i e r a r c h y - - g i v e n the existence o f
class C1. So, within meth21 o f o2, digms, especially to the p a r a d i g m
line 2, it is not always practical.
we might see the following state- of object-oriented design, which is
As a simple example, take C 1 to
m e n t shown graphically in Uniform now becoming m o r e and m o r e
be BIRD and C l 1 2 to be OS-
Object Notation (UON) in Figure 4 popular. F r o m that basis we need to
T R I C H . Methx might be f/y, which
[91: is defined on almost the entire hier- elicit by e x p e r i m e n t the degrees of
o3.meth31 (ol); - - c a l l this line 1 archy u n d e r C l - - e x c e p t C l 1 2 . ill that are caused by the various
Formally speaking, an O S T R I C H is forms o f connascence. These ex-
Let us f u r t h e r assume that within
not a subtype of BIRD; it does not periments would measure the ef-
the m e t h o d meth31 there is a mes-
exhibit a strict superset o f the be- fects o f connascence (both within
sage to the object o l - - t h e object
havior o f BIRD. Nevertheless, it and across encapsulation b o u n d a -
that was j u s t passed to the m e t h o d
seems pedantic in the e x t r e m e not ries) on p r e s u m e d d e p e n d e n t vari-
as shown graphically in Figure 5.
to have the class O S T R I C H inherit ables such as d e b u g g i n g cost and
(This message invokes the method,
from the class B I R D . . . until some maintenance cost.
methx, o f the object o l . In this dis.
object-oriented p r o g r a m m e r tries Connascence represents a set o f
cussion we do not care what the
to get an ostrich to fly, that is. interdependencies in software,
message's p a r a m e t e r s a r e - - i f any.)
some o f which are not readily or
2. Have meth21, the sender o f the
o l . m e t h x ( ........... ); - - c a l l this line 2 immediately a p p a r e n t from the
message in line I, g u a r d against the
code itself. T h e r e f o r e , it would be
T h e issue o f connascence is this: possibility that methx may not be
very valuable if future CASE tools
In line 1 we could have legally d e f i n e d on the class o f the object
were to assist the h u m a n in making
passed an object o11, o f class C l l , sent as the p a r a m e t e r of that mes-
instances o f implicit connascence
or an object o112, o f class C l 1 2 , or sage. Unfortunately, this creates an
m o r e explicit, especially in struc-
indeed an object of any o f the sub- additional c o n n a s c e n c e - - t h i s time
tures that exhibit L 2 - - o r h i g h e r - -
classes o f C1. (See [8, p225] for a between meth21 and m e t h 3 1 - -
encapsulation.
discussion o f this principle.) ][f (see because meth21 needs to know
Finally, since it is unlikely that
line 2) m e t h x is defined on the class what meth31 needs to be g u a r d e d
object orientation (or any o t h e r L2
C1, then there will be no problem; against. Neither does this solution
encapsulation) will be the last word
line 2 will work correctly no matter remove the original connascence; it
in design paradigms, let me suggest
which (legal) object was passed. merely shifts it to being between
six steps t h r o u g h which to base a
However, if methx is defined not meth21 and the class hierarchy
definition o f any future design
on C 1 but only on some classes o f the u n d e r C1.
paradigm:
class hierarchy beneath C1 then Observe that these examples o f
there will be a problem. Effectively, connascence exhibit various de- 1. State the i n t e n d e d p u r p o s e and
what we have done here is to ensure grees of "explicitness." By this, I scope o f applicability o f the para-
that the subclass hierarchy beneath m e a n that some forms of connas- digm.
C1 is not a true subtype hierarchy. cence (e.g., connascence, by name) 2. State the p a r a d i g m ' s encapsula-
This can be achieved either by de- are readily a p p a r e n t from the code tion structure. State what the para-
fining m e t h x on only some of C l ' s itself (or could be revealed by a sim- digm's components are and which
subclasses or by defining it on C1 ple text editor). c o m p o n e n t s are contained within
and then overriding it in some sub- O t h e r cases (e.g., connascence by which.
classes. (See [7] for a further discus- polymorphism) are usually obscure 3. In terms of the encapsulation
sion.) and require h u m a n skill to be re- structure, state the default visibility
In this new situation, line 2 can vealed. It seems likely this latter, rules o f the p a r a d i g m . This will
be m a d e to fail (if, for instance, the implicit form of connascence will prescribe the allowed connections
object passed to meth31 is of class probably incur the greatest devel- a m o n g components and state the
C l 1 2 , which lacks a definition o f o p m e n t a n d maintenance costs. "boundaries o f privacy" established

1SO September 1992/Vol.35, No.9/COMMUNICATIONS OF T H E ACM

 research summaries end
experience reports

by the e n c a p s u l a t i o n structure. neering--design; D.3.3 [Software]: Pro- currently conducting research into
4. List the possible forms o f connas- gram Languages--language constructs methods for applying object-oriented
cence that o b t a i n within this para- and features; 1.6.0 [Computing Method- structures to the problem domains
digm. T h e r e will be explicit connas- dogies]: Simulation and Modeling-- found in business and real-time applica-
general; 1.6.3 [Computing Methodolo- tions. Author's Present Address: Way-
cence, which follows the lines of the
gies]: Simulation and Modeling-- land Systems Inc., Suite 14, 12819
stated e n c a p s u l a t i o n structure a n d applications; K.6.3 [Computing SE 38 St., Bellevue, WA 98006,
visibility, a n d implicit connascence, Milieux]: Management of Computing [email protected].
which will be m o r e difficult to per- and Information Systems--software
ceive because it subtly t r a n s c e n d s management; K.6.4 [Computing
the "official" p a r a d i g m structure. Milieux]: Management of Computing Permission to copy without fee all or part of
and Information Systems--system man- this material is granted provided that the
5. Classify as m u c h as possible the copies are not made or distributed for direct
pernicious effects o f each f o r m o f agement commercial advantage, the ACM copyright
c o n n a s c e n c e in various contexts. General Terms: Design, Methodology notice and the title of the publication and its
6. Suggest heuristics for d e r i v i n g or Additional Key Words and Phrases: date appeal; and notice is given that copying
Analysis, connascence, coupling, model- is by permission of the Association for
m o d i f y i n g software d e s i g n e d u n d e r
ing, visibility Computing MachinelT. To copy otherwise, or
this p a r a d i g m in o r d e r to m i n i m i z e to republish, requires a fee and/or specific
the pernicious effects. [] About the Author: permission.
MEILIR PAGE-JONES is a senior con-
References sultant at Wayland Systems Inc. He is © ACM0002-0782/92/0900-147 $1.50
1. Booch, G. Object-OrientedDesign with
Applications. Benjamin/Cummings,
Redwood City, Calif., 1990.
2. Constantine, L. and Yourdon, E.
Structured Design. Prentice Hall,
Englewood Cliffs, NJ, 1979.
3. DeMarco, T. Structured Analysis and
System Specification. Prentice Hall,
Englewood Cliffs, NJ, 1978.
4. Dijkstra, E. Selected Writings on Com-
puting: A Personal Perspective. m m

Springer-Verlag, New York, NY, Pur , a new software testing tool, detects
1982.
5. Goldberg, A. and Robson, D. run-time errors mid identifies their causes:
Smalltalk-80: The Language. Ad- • Reading tminitialized memory
dison-Wesley, Reading, Mass.,
1989. • Reading or writing freed memory
6. Kay, A. The Reactive Engine. The • Array bounds violations
University of Utah, Department of • Memory Leaks
Computer Science, Aug. 1969.
7. LaLonde, W. and Pugh, J. Subclass- Instruction-level checking
ing not= subtyping not-= is-a. J.
Object-Oriented Prog. 3 5 (1991) 57- • Checks all code, illcluding third party libraries
62.
8. Meyer, B. Object-Oriented Software
• Fast wad comprehensive
Construction. Prentice Hall, Engle-
wood Cliffs, NJ, 1988.
Pure Software currently supports:
9. Page-Jones, M., Constantine, L. and • Cm~dC+ +
Weiss, S. The uniform object nota-
tion. Comput. Lang. (Oct. 1990).
• SunOS 4.1.x
10. Porter III, H.H. Separating the
subtype hierarchy from the inheri-
tance of implementation. J. Object-
m
Puri./j, cml help you create more reliable software. P
m

Oriented Prog. 4, 9 (1992) 20-29. To find out lnore call or send email to i ~ (.O_)pure.com
11. Ross, D.T. and Schoman, K.E.
Structured analysis for require-
(415) 903-5100
ments definition, 1EEE Trans. Soft.
Eng. (Jan. 1977). [ PURE
MAKING SOFTWARE MORE RELIABLE
CR Categories and Subject Descrip- m m

tors: D.2.1 [Software]: Software Engi- n m i m m ii m m m m u m m m II m m n m m m m m II mow m

neering - - requirements~specifications; Circle #86 on Reader Service Card

D.2.10 [Software]: Software Engi-

COMMUNICATIONS OF THE ACM/Septeraber 1992/Vd.35, No.9 lsl