[PDF] - Chapter 11 Implications of Inheritance The decision to supp PDF Document

SLIDE 1 Chapter 11 Implications

f

Inheritance The decision to supp

rt

inheritance and the principle

f

substitutabilit y in a language sets

a

series

f

c hain reactions that end up impacting almost ev ery asp ect

f

a programming language. In this c hapter, w e will illustrate this p

in

t b y considering some

f

the implications

f

the decision to supp

rt

in a natural fashion the idea

f

the p

lymorphic

v ariable. The links b et w een inheritance and

ther

language features can b e summarized as follo ws:

In
rder

to mak e the most eectiv e use

f
b

ject-orien ted tec hniques, the language m ust supp

rt

the p

lymorphic

v ariable. A p

lymorphic

v ariable is a v ariable that is declared as

ne

t yp e but actually main tains a v alue deriv ed from a subt yp e

f

the declared t yp e.

Because

at compile time w e cannot determine the amoun t

f

memory that will b e required to hold the v alue assigned to a p

lymorphic

v ariable, all

b

jects m ust reside

n

the heap, rather than

n

the stac k.

Because

v alues are heap residen t, the most natural in terpretation

f

assignmen t and parameter passing uses reference seman tics, rather than cop y seman tics.

Similarly

, the most natural in terpretation

f

equalit y testing is to test

b

ject iden tit y . Ho w ev er, since

ften

the programmer requires a dieren t meaning for equalit y , t w

dieren

t

p

erators are necessary .

Because

v alues reside

n

the heap, there m ust b e some memory managemen t mec hanism. Because assignmen t is b y reference seman tics, it is dicult for the programmer to determine when a v alue is no longer b eing used. Therefore a garbage collection system is necessary to reco v er un used memory . Eac h

f

these p

in

ts will b e more fully dev elop ed in the follo wing sections. 189

SLIDE 2 190 CHAPTER 11. IMPLICA TIONS OF INHERIT ANCE 11.1 The P

lymorphic

V ariable As w e will see in Chapter 12, a great deal

f

the p

w

er

f

the

b

ject-orien ted features

f

Ja v a comes through the use

f

a p

lymorphic

variable. A p

lymorphic

v ariable is declared as main taining a v alue

f
ne

t yp e, but in fact holds a v alue from another t yp e. W e ha v e seen man y suc h examples in the sample programs presen ted in P art 1. F

r

instance, m uc h

f

the standard user in terface co de thinks

nly

that an application is an instance

f

class F rame, when in fact eac h program w e created used inheritance to create a new t yp e

f

application. Similarly , in the pin ball game construction program (Chapter 7) a v ariable w as declared as holding a v alue

f

t yp e PinBallT a rget, when in fact it w

uld

hold a Hole

r

a Sco reP ad. Figure 11.1 pro vides a class hierarc h y consisting

f

three classes, Shap e and t w

sub

classes Circle and Squa re. In the small test program sho wn b elo w v ariable named fo rm is declared as t yp e Shap e, then assigned a v alue

f

t yp e Circle. As exp ected, when the function describ e() is in v

k

ed, the metho d that is executed is the pro cedure in class Circle, not the function inherited from class Shap e. W e will use this example class in the subsequen t discussion in this c hapter. class ShapeTest f static public void main (String [ ] args) f Shape form = new Circle (10, 10, 5); System.out.prin tln (" for m is " + form.describe()); g g 11.2 Memory La y

ut

Before w e can describ e the impact

f

the p

lymorphic

v ariable

n

memory managemen t, it is rst necessary to review ho w v ariables are normally represen ted in memory in most programming languages. F rom the p

in

t

f

view

f

the memory manager, there are t w

ma

jor categories

f

memory v alues. These are stack b ase d memory lo cations, and he ap b ase d memory v alues. Stac k based memory lo cations are tied to pro cedure en try and exit. When a pro cedure is started, space is allo cated

n

a run-time stac k for lo cal v ariables. These v alues exist as long as the pro cedure is executing, and are erased, and the memory reco v ered, when the pro cedure exits. Figure 11.2 sho ws, for example, a snapshot

f

the run-time stac k for the follo wing simple recursiv e algorithm: class FacTest f static public void main (String [ ] args) f int f = factorial(3);

SLIDE 3 11.2. MEMOR Y LA YOUT 191 class Shape f protected int x; protected int y; public Shape (int ix, int iy) f x = ix; y = iy; g public String describe () f return "unknown shape"; g g class Square extends Shape f protected int side; public Square (int ix, int iy, int is) f super(ix, iy); side = is; g public String describe () f return "square with side " + side; g g class Circle extends Shape f protected int radius; public Circle (int ix, int iy, int ir) f super(ix, iy); radius = ir; g public String describe () f return "circle with radius " + radius; g g Figure 11.1: Shap e classes and P

lymorphic

V ariable

SLIDE 4 192 CHAPTER 11. IMPLICA TIONS OF INHERIT ANCE 8 4 c: 2 r: ? n: 3 8 4 c: 1 r: ? n: 2 8 4 c: r: 1 n: 1 record activ ation rst record activ ation second record activ ation third Figure 11.2: A Snapshot

f

the Activ ation F rame Stac k System.out.prin tln (" Fac to ria l

f

3 is " + f); g static public int factorial (int n) f int c = n

1;

int r; if (c > 0) r = n

factorial(c);

else r = 1; return r; g g The snapshot is tak en after the pro cedure has recursed three times, just as the innermost pro cedure is starting to return. The data v alues for three pro cedures are sho wn. In the innermost pro cedure the v ariable r has b een assigned the v alue 1, while the t w

p

ending pro cedures the v alue

f

r has y et to b e determined. There are a n um b er

f

adv an tages

f

stac k based memory allo cation. All lo cal v ariables can b e allo cated

r

deallo cated as a blo c k, for example, instead

f
ne

b y

ne.

This blo c k is commonly called an activation r e c

r

d. In ternally , v ariables can b e describ ed b y their n umeric

set

within the activ ation record, rather than b y their sym b

lic

address. These n umeric

sets

ha v e b een noted in Figure 11.2. Most mac hines are m uc h more ecien t at dealing with n umeric

sets

than with sym b

lic

names. Notice that eac h new activ ation record creates a new set

f
sets,

so that the

set

is alw a ys relativ e to the activ ation frame in whic h a v ariable app ears.

SLIDE 5 11.2. MEMOR Y LA YOUT 193 There is

ne

serious disadv an tage to stac k based allo cation. This is that these n umeric

sets

asso ciated with v ariables m ust b e determined at compile time, not a run time. In

rder

to do this, the compiler m ust kno w the amoun t

f

memory to assign to eac h v ariable. In Figure 11.2, the compiler

nly

kno ws that v ariable c can b e found at address 8 b ecause it kno ws that v ariable r, whic h starts at lo cation 4, requires

nly

four b ytes. But, this is exactly the information w e do not kno w for a p

lymorphic

v ariable. The storage requiremen ts for a p

lymorphic

v ariable v alue are determined when the v alue is created at run-time, and can ev en c hange during the course

f

execution. Recall the classes sho wn in Figure 11.1, and the memory requiremen ts for the pro cedure main in the sample program describ ed earlier. Here the v ariable fo rm, whic h is declared as holding a Shap e, can at

ne

momen t b e holding a Circle, at another a Square, and so

n.

Both the sub classes add additional data elds that are not found as part

f

the paren t class. Th us the translator cannot kno w, at compile time, exactly ho w m uc h memory will b e required to hold the v ariable fo rm. In Ja v a, the solution to this problem is that

b

jects are not stored

n

the activ ation record stac k, but are instead stored

n

the heap. A heap is an alternativ e memory managemen t system,

ne

that is not tied to pro cedure en try and exit. Instead, memory is allo cated

n

the heap when explicitly requested (to create a new

b

ject, using the new

p

erator), and is freed, and recycled, when no longer needed. A t run-time, when the memory is requested, the Ja v a system kno ws precisely ho w m uc h memory is required to hold a v alue. In this fashion the Ja v a language a v

ids

the need to predict, at compile time, the amoun t

f

memory that will b e needed at run-time. The co de generated b y the compiler, ho w ev er, m ust still b e able to accesses v ariables through n umeric

sets,

ev en through the actual heap addresses will not b e kno wn un til run time. The solution to this dilemma is to use

ne

lev el

f

indirection. Lo cal v ariables are represen ted

n

the stac k as p

in

ter v alues. The size

f

a p

in

ter is kno wn at compile time, and is indep enden t

f

the size

f

the

b

ject it p

in

ts to. This p

in

ter eld is lled when an

b

ject is created. It is said that the programming language Ja v a has no p

in

ters. This is true as far as the language the programmer sees is concerned. But ironically , this is

nly

p

ssible

b ecause al l

b

ject v alues are, in fact, represen ted in ternally b y p

in

ters. 11.2.1 An Alternativ e T ec hnique It should b e noted that the solution to this problem selected b y the designers

f

Ja v a is not the

nly

p

ssibilit

y . This can b e illustrated b y considering the language C++, that uses an en tirely dieren t approac h. C++ treats assignmen t

f

variables and assignmen t

f

p

inters

v ery dieren tly . The designers

f

C++ elected to store v ariable v alues

n

the stac k. Th us, the memory allo cated to a v ariable

f

t yp e Shap e is

nly

large enough to hold a v alue

f

t yp e Shap e, not the additional elds added b y the sub class Circle. During the pro cess

f

assignmen t these extra elds are simply sliced

and

discarded. Of course, the resulting v alue is then no

SLIDE 6 194 CHAPTER 11. IMPLICA TIONS OF INHERIT ANCE longer a Circle. F

r

this reason, when w e try to execute a mem b er function, suc h as the describ e function, the co de executed will b e that asso ciated with class Shap e, not the v alue asso ciated with class Circle, as in Ja v a. The programmer who uses b

th

C++ and Ja v a should b e a w are

f

this subtle, but nev ertheless imp

rtan

t dierence. 11.3 Assignmen t In Section 11.2 w e describ ed wh y v alues in Ja v a are most naturally main tained

n

the heap, rather than b eing held in the activ ation record stac k. Because to the compiler the underlying \v alue"

f

a v ariable is simply a p

in

ter in to the heap, the most natural seman tics for assignmen t simply cop y this p

in

ter v alue. In this manner, the righ t and left sides

f

an assignmen t statemen t end up referring to the same

b

ject. This is

ften

termed r efer enc e seman tics (sometimes also called p

inter

seman tics). The consequences

f

this in terpretation

f

assignmen t are subtle, but are again a k ey p

in

t for Ja v a programmers to remem b er. Supp

se

w e create a simple class Bo x as follo ws: public class Box f private int value; public Box () f value = 0; g public void setValue (int v) f value = v; g public int getValue () f return value; g g No w imagine that w e create a new b

x,

assign it to a v ariable x, and set the in ternal v alue to 7. W e then assign the b

x

held b y x to another v ariable named y. Since b

th

x and y no w hold non-n ull v alues

f

t yp e Bo x, the programmer migh t assume that they are distinct. But, in fact, they are exactly the same b

x,

as can b e v eried b y c hanging the v alue held in the y b

x

and prin ting the v alue held b y the x b

x:

public class BoxTest f static public void main (String [ ] args) f Box x = new Box(); x.setValue (7); // set v alue

f

x Box y = x; // assign y the same v alue as x y.setValue (11); // c hange v alue

f

y System.out.prin tln (" con te nts

f

x " + x.getValue()); System.out.prin tln (" con te nts

f

y " + y.getValue());

SLIDE 7 11.3. ASSIGNMENT 195 g g The k ey

bserv

ation is that the t w

v

ariables, although assigned separate lo cations

n

the activ ation record stac k, nev ertheless p

in

t to the same lo cation

n

the heap: y x a b

x
*

H H H H H H j 11.3.1 Clones If the desired eect

f

an assignmen t is indeed a cop y , then the programmer m ust indicate this. One w a y w

uld

b e to explicitly create a new v alue, cop ying the in ternal con ten ts from the existing v alue: // create new b

x

with same v alue as x Box y = new Box (x.getValue()); If making copies is a common

p

eration, it migh t b e b etter to pro vide a metho d in the

riginal

class: public class Box f ... public Box copy() f // mak e cop y

f

b

x

Box b = new Box(); b.setValue (getValue()); return b; g ... g A cop y

f

a b

x

is then created b y in v

king

the cop y() metho d: // create new b

x

with same v alue as x Box y = x.copy();

SLIDE 8 196 CHAPTER 11. IMPLICA TIONS OF INHERIT ANCE There is no general mec hanism in Ja v a to cop y an arbitrary

b

ject, ho w ev er the base class Object do es pro vide a protected metho d named clone() that creates a bit-wise cop y

f

the receiv er, as w ell as an in terface Cloneable that represen ts

b

jects that can b e cloned. Sev eral metho ds in the Ja v a library require that argumen ts b e v alues that are cloneable. T

create

a class that is cloneable, the programmer m ust not

nly
v

erride the clone metho d to mak e it public, but also explicitly indicate that the result satises the Cloneable in terface. The follo wing, for example, sho ws ho w to create a cloneable b

x.

public class Box implements Cloneable f private int value; public Box () f value = 0; g public void setValue (int v) f value = v; g public int getValue () f return value; g public Object clone () f Box b = new Box(); b.setValue (getValue()); return b; g g The clone metho d is declared as yielding a result

f

t yp e Object. This prop ert y cannot b e mo died when the metho d is

v

erridden. As a consequence, the result

f

cloning a v alue m ust b e cast to the actual t yp e b efore it can b e assigned to a v ariable. public class BoxTest f static public void main (String [ ] args) f Box x = new Box(); x.setValue (7); Box y = (Box) x.clone(); // assign cop y

f

x to y y.setValue (11); // c hange v alue

f

x System.out.prin tln (" con te nts

f

x " + x.getValue()); System.out.prin tln (" con te nts

f

y " + y.getValue()); g g

SLIDE 9 11.3. ASSIGNMENT 197 As alw a ys, there are subtleties here that can trap the un w ary programmer. Consider the

b

ject that is b eing held b y

ur

b

x.

Imagine, instead

f

simply an in teger, that it is something more complex, suc h as a Shap e. Should a clone also clone this v alue,

r

just cop y it? A cop y results in t w

distinct

b

xes,

but

nes

that share a common v alue. This is called a shal low c

py.

y x a b

x

a b

x
a

shap e

*

H H H H H H j Cloning the con ten ts

f

the b

x

(whic h m ust therefore b e itself a t yp e that is cloneable) results in t w

b
x

v alues whic h are not

nly

themselv es distinct, but whic h p

in

t to v alues that are also distinct. This is termed a de ep c

py.

y x a b

x

a b

x
a

shap e a shap e

Whether

a cop y should b e shallo w

r

deep is something that m ust b e determined b y the programmer when they

v

erride the clone in terface. 11.3.2 P arameters are a form

f

Assignmen t Note that a v ariable passed as an argumen t to a mem b er function can b e considered to b e a form

f

assignmen t, in that the parameter passing, as with assignmen t, results in the same v alue b eing accessible through t w

dieren

t names. Th us, the issues raised in Section 11.3 regarding assignmen t apply equally to parameter v alues. Consider the function sneeky in the follo wing example, whic h mo dies the v alue held in a b

x

that is passed through a parameter v alue. public class BoxTest f static public void main (String [ ] args) f

SLIDE 10 198 CHAPTER 11. IMPLICA TIONS OF INHERIT ANCE Box x = new Box(); x.setValue (7); sneeky (x); System.out.prin tln (" con te nts

f

x " + x.getValue()); g static void sneeky (Box y) f y.setValue (11); // c hange v alue

f

parameter g g A programmer who passes a b

x

to this function, as sho wn in the main pro cedure, could subsequen tly see the resulting c hange in a lo cal v ariable. A Ja v a programmer should alw a ys k eep in mind that when a v alue is passed to a pro- cedure, a certain degree

f

con trol

v

er the v ariable is lost. In particular, the pro cedure is free to in v

k

e an y metho d applicable to the parameter t yp e, whic h could result in the state

f

the v ariable b eing c hanged, as in this example. 11.4 Equalit y T est F

r

basic data t yp es the concept

f

equalit y is relativ ely simple. The v alue 7 should clearly b e equiv alen t to 3 + 4, for example, b ecause w e think

f

in tegers as b eing unique en tities{there is

ne

and

nly
ne

7 v alue. This is true ev en when there are t w

syn

tactic represen tations for the same quan tit y , for example the ASCI I v alue

f

the letter a is 141, and th us '\141' is the same as 'a'. The situation b ecomes sligh tly more complicated when the t w

v

alues b eing dened are not the same t yp e. F

r

example, should the v alue 2 (an in teger constan t) b e considered equal to 2.0 (a

ating-p
in

t constan t)? The Ja v a language sa ys that the t w

v

alues are equiv alen t in this case, since the in teger v alue can b e c

nverte

d in to a

ating

p

in

t v alue, and the t w

ating

v alues compared. Th us, all the follo wing expressions will yield a true result. 7 == (3 + 4) a == \141 2 == 2.0 When the concept

f

equalit y testing is expanded to include

b

jects, the most natural in terpretation b ecomes less

b

vious. In Section 11.3 it w as argued that b ecause

b

jects are

SLIDE 11 11.4. EQUALITY TEST 199 in ternally represen ted b y p

in

ters, the natural in terpretation

f

assignmen t uses reference seman tics. One in terpretation

f

equalit y testing follo ws the same reasoning. That is, t w

b

jects can b e considered equal if they are iden tically the same. This form

f

equalit y testing is

ften

termed as testing

b

ject identity, and is the in terpretation pro vided b y the

p

erator == and its in v erse, the

p

erator ! =. This can cause certain anomalies. F

r

example, although 7 is equal to 3 + 4, the follo wing co de fragmen t will nev ertheless sho w that an Integer v alue 7 is a distinct

b

ject from a dieren t Integer

b

ject, ev en if it has the same v alue: Integer x = new Integer(7); Integer y = new Integer(3 + 4); if (x == y) System.out.prin tln (" equ iv ale nt ") ; else System.out.prin tln (" not equivalent"); The Ja v a compiler do es apply t yp e c hec king rules to the t w

argumen

ts, whic h will help detect man y programming errors. F

r

example, although a n umeric v alue can b e compared to another n umeric, a n umeric cannot b e compared to a dieren t t yp e

f
b

ject (for example, a String). Tw

b

ject v alues can b e compared if they are the same t yp e,

r

if the class

f
ne

can b e con v erted in to the class

f

the second. F

r

example, a v ariable that w as declared to b e an instance

f

class Shap e could b e compared with a v ariable

f

t yp e Circle, since a Circle w

uld

b e con v erted in to a Shap e. A particular instance

f

the con v ersion rule is

ne
f

the more frequen t uses

f

the ==

p

erator; namely , an y

b

ject can b e compared to the constan t null, since the v alue null can b e assigned to an y

b

ject t yp e. Often

b

ject iden tit y is not the relation

ne

w

uld

lik e to test, and instead

ne

is in- terested in

b

ject e quality. This is pro vided b y the metho d equals, whic h is dened b y the base class Object and redened b y a n um b er

f

classes. The follo wing, for example, w

uld

return true using the equals function, but w

uld

not b e true using the ==

p

erator: String a = "abc"; String b = "abc"; Integer c = new Integer(7); Integer d = new Integer(3 + 4); if (a.equals(b)) System.out.prin tln (" str in gs are equal"); if (c.equals(d)) System.out.prin tln (" int eg ers are equal"); Because the equals function is dened in class Object, it can b e used with an y

b

ject t yp e. Ho w ev er, for the same reason, the argumen t is declared

nly

as t yp e Object. This

SLIDE 12 200 CHAPTER 11. IMPLICA TIONS OF INHERIT ANCE means that an y t w

b

jects can b e compared for equalit y , ev en if there is no p

ssible

w a y that for either to b e assigned to the

ther:

if (a.equals(c)) // can nev er b e true System.out.prin tln (" str in g equal to integer"); The dev elop er

f

a class is free to

v

erride the equals

p

erator and thereb y allo w comparison b et w een

b

jects. Since the argumen t is an Object it m ust rst b e tested to ensure it is the correct t yp e. By con v en tion, the v alue false is returned in cases where the t yp e is not correct. The follo wing, for example, w

uld

b e ho w

ne

could dene a function to compare t w

instances
f

class Circle (Figure 11.1). class Circle extends Shape f ... public boolean equals (Object arg) f if (arg instanceof Circle) f // con v ert argumen t to circle Circle argc = (Circle) arg; if (radius == argc.radius) return true; // just test radius g return false; // return false

therwise

g g Because the t yp e

f

the argumen t is not necessarily the same as the t yp e

f

the receiv er, un usual situations can

ccur

if the programmer is not careful. F

r

example, supp

se

w e dened equals in class Shap e from Figure 11.1 to test equalit y

f

the x and y v alues, but forgot to also

v

erride the function in class Squa re. It could happ en in this situation that if w e tried to compare a square and a circle, the comparison w

uld

b e true

ne

w a y and false the

ther.

Square s = new Square(10, 10, 5); Circle c = new Circle(10, 10, 5); if (s.equals(c)) // true, since metho d in shap e is used System.out.prin tln (" squ ar e equal to circle"); if (c.equals(s)) // false, since metho d in circle is used System.out.prin tln (" cir cl e equal to square"); When

v

erriding the equals metho d the programmer should b e careful to a v

id

this problem, and ensure that the resulting functions are b

th

symmetric (if x is equal to y , then y is equal to x) and asso ciativ e (if x is equal to y and y is equal to z , then x is equal to z ).

SLIDE 13 11.5. GARBA GE COLLECTION 201 A go

d

rule

f

th um b is to use == when testing n umeric quan tities, and when testing an

b

ject against the constan t null. In all

ther

situations the function equals should b e used. 11.5 Garbage Collection In Section 11.2 it w as argued that supp

rt

for p

lymorphic

v ariables naturally implies that v alues are allo cated

n

the heap, rather than

n

the stac k. Memory

f

an y t yp e is alw a ys a nite resource, whic h m ust b e managed if a program is to a v

id

running

ut
f

storage. In

rder

to prev en t this problem, b

th

stac k and heap based memory is recycled, with new memory requests b eing assigned the same lo cations as previous memory v alues that are no longer b eing used. Unlik e stac k based memory allo cation, heap based memory managemen t is not tied to pro cedure activ ation, and is th us not automatically reco v ered when a pro cedure returns. This means an alternativ e mec hanism m ust b e in tro duced. Tw

dieren

t approac hes to the reco v ery

f

heap based memory v alues are found in programming languages. In languages suc h as Ob ject P ascal

r

C++ it is up to the programmer to explicitly indicate when a memory v alue is no longer b eing used, and can therefore b e reused to satisfy new memory requests. In Ob ject P ascal, for example, this is accomplished b y means

f

the statemen t disp

se:

var aShape : Shape; begin new (aShape); ( allocate a new shape ) ... dispose (aShape); ( free memory used by variable ) end. In suc h languages, if an

b

ject is to b e freed, it m ust b e \o wned" b y some v ariable (the v ariable that will b e the target for the free request). But Ja v a v alues are simply references, and are shared equally b y all v ariables that refer to the same v alue. If a programmer assigns a v alue to another v ariable,

r

passes the v alue as an argumen t, the programmer ma y no longer b e a w are

f

ho w man y references a v alue migh t ha v e. Lea ving to the programmer the resp

nsibilit

y for freeing memory in this situation exp

ses

a program to a n um b er

f

common errors, suc h as freeing the same memory lo cation t wice. Ev en more commonly , programmers a v

id

committing this error b y simply nev er freeing memory , causing long-running programs to slo wly degrade as they consume more and more memory resources. F

r

these reasons, the designers

f

Ja v a elected a dieren t approac h. Rather than ha ving the programmer indicate when a v alue is no longer needed, a run-time system is pro vided that p erio dically searc hes the memory b eing used b y a program to disco v er whic h heap

SLIDE 14 202 CHAPTER 11. IMPLICA TIONS OF INHERIT ANCE v alues are b eing accessed and, more imp

rtan

tly , whic h heap v alues are no longer b eing referenced b y an y v ariable and can therefore b e reco v ered and recycled. This mec hanism is kno wn as the garb age c

l

le ction system. The use

f

a garbage collection system in Ja v a is a compromise. The task

f

garbage collection do es exact a toll in execution time. Ho w ev er, in return a garbage collection system greatly simplies the programming pro cess, and eliminates sev eral categories

f

common programming errors. F

r

most programs, the impro v emen ts in reliabilit y are w ell w

rth

the execution time

v

erhead. 11.6 Chapter Summary The idea

f

a p

lymorphic

v ariable is an extremely p

w

erful concept,

ne

w e will explore in detail in later c hapters. Ho w ev er, the decision to supp

rt

the concept

f

a p

lymorphic

v ariable raises a n um b er

f

subtle and dicult issues in

ther

asp ects

f

the language. In this c hapter w e ha v e in v estigated some

f

these, sho wing ho w inheritances alters the w a y the language m ust handle storage managemen t, the concept

f

assignmen t, and the testing

f

t w

v

alues for equalit y . Study Questions 1. What is a p

lymorphic

v ariable? 2. F rom the language implemen tation p

in

t

f

view, what are the t w

ma

jor categories

f

memory v alues? 3. Ho w do es the idea

f

a p

lymorphic

v ariable conict with the abilit y to determine memory requiremen ts at compile time? 4. What do es it mean to sa y that Ja v a uses reference seman tics for assignmen t? 5. What m ust a programmer do to create a class that supp

rts

the Cloneable in terface? 6. What is the dierence b et w een a deep and shallo w cop y? 7. In what w a y is passing a parameter similar to an assignmen t? 8. What is the dierence b et w een the ==

p

erator and the equals() metho d? 9. What task is b eing p erformed b y the garbage collection system in the Ja v a run-time library? 10. What are some adv an tages

f

a language that uses garbage collection? What are some disadv an tages?

SLIDE 15 11.6. CHAPTER SUMMAR Y 203 Exercises 1. Rewrite the Shap e classes sho wn in Figure 11.1 so that they supp

rt

the cloneable in terface. 2. Rewrite the class Bo x so that it holds v alues that are cloneable, and when cloned it created a deep cop y .