Apple, Inc. v. Motorola, Inc. et al

Filing 93

Declaration of Christine Saunders Haskett filed by Plaintiffs Apple, Inc., NEXT SOFTWARE, INC. re: 90 Motion Requesting Claims Construction (Attachments: # 1 Ex. 21 IEEE Dictionary, # 2 Ex. 22 '575 file history, # 3 Ex. 23 '486 file history, # 4 Ex. 24 Order No. 18, # 5 Ex. 25 '705 file history, # 6 Ex. 26 '647 file history, # 7 Ex. 27 Brad Cox, # 8 Ex. 28 Microsoft Press Dictionary, # 9 Ex. 29 '002 file history, # 10 Ex. 30 Dictionary of Computer Words, # 11 Ex. 31 Computer Dictionary, # 12 Ex. 32 Academic Press Dictionary, # 13 Ex. 33 IBM Dictionary, # 14 Ex. 34 Black's Law Dictionary, # 15 Ex. 35 About 3GPP, # 16 Ex. 36 '919 patent, # 17 Ex. 37 '713 provisional application) (Haslam, Robert)

EXHIBIT 27

Object-Oriented
Programming
An Evolutionary Approach

Brad J. (ox, Ph.D.
Productivity Products International

y4y ADDISON-WESLEY PUBLISHING COMPANY
Reading, Massachusetts • Menlo Park, California
Don Mills, Ontario • Wokingham, England • Amsterdam
Sydney • Singapore • Tokyo • Madrid
Bogota • Santiago • San Juan

Library of Congress Cataloging-in-Publication Data
Cox, Brad J., 1944
Object-oriented programming.
Includes index.
1. System design. 2. Computer software.
I. Title.
QA76.9.S8~C69 1986
003
85-22921
ISBN 0-201-10393-1

Many of the designations used by manufacturers and
sellers to distinguish their products are claimed as
trademarks. Where those designatipns appear in this
book, and Addison-Wesley was aware pf a trademark
claim, the designations have been printed ill initial
caps or all caps.

Reprinted with corrections April, 1987
Copyright © 1986 by Productivity Product? International, Inc., Sandy Hook, CT 06482.
All rights reserved. No part of this publication may be reproduced, stored in a retrieval
system, or transmitted, in any form or by any means, electronic, mechanical, photocopyjng,
recording, or otherwise, without the prior written permission of the puplisher. Printed in
the United States of America. Published siir)ultpneously jn Canada.

IJ-HA-89

I Two

Why Object-oriented
Programming?

O

bject-oriented programming is not so much a coding technique as it
is a code packaging te.chnique, a way for code suppliers to encapsu------late functionality for delivery to consumers. It is this incr~.a",§~9-_.~I!!Pl1~s.is
o.!!J.hl?JeJ~~.igIlshipbetween eQl1Sllm~r.~a.IldsuppHers code that separates object-oriented and conventional programming (Figure 2.1).
Binding is the process of integrating functionality from different suppliers
into a consumer's code (Figure 2.2). Binding is more than what most programmers call linking; determining which binary modules must be combined to
produce an executable image, assigning a memory address to each one, and
patching external references with the correct memory addresses. Binding is
the process whereby operators and operands oLP.oJ.l?l1ti('!JlY ..!p:'a~~.iiif~~~!!t
types are.:published by suppliers and used by consumers.
.
-Th~;a~e-severalschoois ()(th~~ght ;bout-;h~~~~d how binding should /i~k!fJ
be done, each with distinct strengths and weaknesses. The early binding f?"
approach is the most widely known because it is the only approach provided
in most conventional languages. With early binding, binding occurs while the
consumer's code is being compiled so that the consumer and his tools (the
compiler) bear responsibility for binding. Delayed binding (also known as late
binding or dynamic binding) means that binding is done later than compiletime, generally while the program is running. Delayed binding moves responsibility for binding away from the consumer and onto the operands, effectively onto the supplier who defined this type of operand.
These approaches are not equjvalent. They are different tools for different
jobs. The difference is in the degree to which the design of a collection's

gf

13

14
Object-oriented Programming:

An Evolutionary Approach

Supplier

Comput er

JII UI

o

iillili.

Figure 2.1. Progra mbuildi ng versus systembuildi ng. Conve ntiona l
progra mmin g tools empha size the relatio nship between a progra mmer and
his code, while objectorient ed progra mmin g
empha sizes the relatio nship betwe en suppli ers and
consum ers of code.

degre e to
conte nts can be allow ed to affect the desig n of the collection; the
(Figu re 2.3).
which the consu mer's code is coupled to that of the suppl iers'
y coupl ed
Lang uages that provid e early bindin g are ideal for build ing tightl
ed by each
collec tions where all uncer tainty about the data type provid
code is
suppl ier can be remov ed at or before the time the consu mer's
tions where the
comp iled. Dyna mic bindi ng is neede d in loosely coupled collec
on until the
consu mer's code canno t predi ct the type of data to be opera ted
code is being run.
al bindThis chapt er shows the effect of this coupl ing by contr asting sever
numb er of
ing appro aches -in a small exam ple-a progr am for count ing the
uniqu e words in a file.

Supplier

Supplier

Bindin g.
Bindin g is the process of
assem bling compo nents
from differe nt suppli ers
into a larger compo nent
belong ing to the consumer.
Figure 2.2.

23
Chapter Two

Why Object-oriented Programming?

a programmer might like to compute the vector to its bottom right corner by
writing
vector bottomRight = origin

+

extent;

This is not possible in C, nor in other conventional languages like Pascal,
FORTRAN, and COBOL.3 These languages do not allow the programmer to
change the meaning of built-in operators like +, so that these operators
cannot be applied to newly added data types like vector. These languages
require the programmer to decompose each operation to primitive types
manually and write:
bottomRight.x = origin.x + extent.x;
bottomRight.y = origin.y + extent.Yi

The supplier of a new data type like vector cannot hide the implementation of
this new type from consumers. They must know the implementation to use
the type, because they must do all binding between vector and operations on
vectors manually whe!"l; they write their code.
The recent trend is toward languages that do provide this flexibility, as
long as all types are known at compile-time. For example, languages like Ada
allow vectors to be defined as a new data type with +, a legal operation on
that type. When compiling the expression
bottomRight = origin + extent

the compiler notices that both origin and extent are vectors, and determines
that a special meaning for the + operator is to be used-the one defined by the
supplier of the vector type. These languages provide early binding in a more
powerful way than C because the meaning of predefined operators like + can
be changed for newly defined data types.
This approach can address some of the difficulties encountered when applying subroutine libraries to the UniqueWords problem. The problem was to
build a new data type, Set, without prematurely committing to the kind of
elements to be stored in the Set. Ada's solution to this class of problem is
called a generic package, which is a package of code with a compile-time
parameter that specifies which type is to be managed ~y the set. The
UniqueWords application would be solved by writing a statement in the
consumer's code that directs the compiler to compile a Set that expects to
manage ByteArrays.

Dynamic Binding and Loosely Coupled Collections
The statically bound languages are perfect for building tightly coupled
collections like vectors and rectangles. They can even be pushed to handle

3But it is possible in C++. See Chapter 3.

I

24
Object-oriented Programming:

An Evolutionary Approach

piling a
some harde r cases like the UniqueWords examp le. Of cours e recom
be a probsuppl ier's code every time a consu mer provides a new data type can
sets and the
lem, and not only becau se of the time to compile these custo m
suppl ier
memo ry to store them in. A more funda menta l conce rn is that the
t hold in
must trust the comp iler to prote ct any propr ietary intere st he migh
ic packthose sources. It is hard to see how a comm ercial marke tplace in gener
to protec t
ages could develop as long as suppl iers must trust the comp iler
their propr ietary intere sts in sourc e code.
extrem ely
It is less widel y recog nized that static ally bound langu ages are
the automopoor for build ing loosely coupled collec tions- probl ems more like
d in applicabile's trunk than its engin e. Loosely coupled collections aboun
DeskTop,
tions like office autom ation, in inform ation- orient ed ensem bles like
p or a
Envel ope, FileFo lder, Paper Clip, Mailbox, and FileC abine t. A deskto
le nor desirmailb ox is a loosely coupl ed collection becau se it is neith er possib
what kind
able to state, at any point earlie r than when the deskto p is in use,
of items it conta ins.
bindi ng
When every data type is know n when the code is compiled, static
is no
works . Other wise bindi ng must be done dynam ically , period . There
ng is intrin choice betwe en static and dynam ic bindin g, since dynam ic bindi
there is a
sic to the very essen se of a loosely coupled collection. However,
anoth er,
choice betwe en one metho d of imple menti ng dynam ic bindi ng and
statesince dynam ic bindi ng can be done either manu ally, by condi tional
ammi ng
ments writte n by the progr amme r, or autom atical ly, by the progr
langu age and the run-ti me enviro nmen t.
s in
The choice is show n in Figur e 2.4. This figure shows the kinds of object
work of a
an office autom ation projec t as seven folders, each repre sentin g the
ox develdiffer ent progr amme r. The mailb ox folder is open to show the mailb
oper's two choices for how to imple ment dynam ic bindin g.
deterThe left fragm ent shows the manu al appro ach. A switcl i statem ent
to the opermines which kind of object is on hand, passin g contro l dynam ically
The kind of
ation (a C functi on) that prope rly manip ulates that kind of object.
a C strucobject is repre sente d in a field inside each object, repre sente d as
ture:
!

struct OfficeMemo { int type; •.. } ;
struct WhiLeYouWereOutNotice { int type; ..• } ;
struct FiLeFoLder { int type; ... } ;

dynam ic
The fragm ent on the right shows the other appro ach in which
The mailbindi ng is provi ded autom atical ly by the progr ammi ng langu age.
, specifies
box developer, as consu mer of the other six data types in this system
doThisJ, and
what each item is to do by writin g the messa ge expre ssion [item
d be accomit is up to the object to decide how the comm and, doThis, shoul
plishe d for that kind of object.
ation of
The differ ence betwe en these two appro aches is crucia l to the separ
oper is the
respo nsibil ity betw:een suppl ier and consumer. The mailb ox devel

25
Chapter Two

Why Object-oriented Programming?

Calendar

(

I

FileFolder

I
(

Envelope

I
/

(WhileYOuWereOu! \

PriceList

~

I

Mailbox

Einding done by each consumer

ExpenseA

item = nextltemlnMailbox();
switch(item->type) (
case EXPENSEACCOUNT: expOp();
case PRICELIST: priceOp();
case WHILEYOUWEREOUT: whileYo
case ENVELOPE:
case FILEFOLDE Binding done by each supplier
case CALENDAR:
item = nextltemlnMailbox();
default:
[item doThis];
}

l----rt
I

Non-reusable
Tight coupling

II

Reusable
Loose coupling

t---

\

I

I

Figure 2.4. Binding in a
loosely coupled collection.
Dynamic binding can be
implemented either by the
consuIller or by the supplier. The former leads to
nonreusable code, because
the consumer's code enumerates the set of data
types that were known
when the consumer's code
was written. The latter Cl:j.n
produce reusable code,
because data types are
mentioned in only one
place-in the files that
define each data type.

consumer of functionality provided elsewhere in his project. The first
approach requires that he, the consumer, bear the responsibility for determining which supplier's data is at hand in the mailbox and for selecting which
one of the supplier's subroutines is proper for that kind of data. This is called
consumer-side binding. By contrast, the other approach puts that responsibility right where it belongs, on the supplier's side.
The problem with consumer-side binding can be seen in the case labels in
the switch statement. These labels explicitly enumerate the data types this
mailbox is prepared to handle, SQ each time a new type is added anywhere in
this system, the mailbox code must be changed. Something foul has leaked
across the boundary that should have isolated suppliers from consumers.
This mailbox is useless in any other application, because the case labels
explicitly state that it will only work correctly for those six types.
One effect of consumer-side binding is lack of reusability. It forces the mailbox to be written in a way that prevents it from ever being reused in other
.
.
applications. Consumer-side binding also leads to lack of malleability. Each
time a new data type is added to the system, the source for the mailbox must
be modified. It cannot withstand the kind of evolutionary changes discussed
in Chapter 1. Supplier-side binding, by contrast, increases the chance that
the mailbox can be reused in other applications because it no longer mention$
types that might change in some new application. And the system becomes
malleable because new data types can be added over time without impacting
working code.
.