Errata

Head First Object-Oriented Analysis and Design

Errata for Head First Object-Oriented Analysis and Design

Submit your own errata for this product.

The errata list is a list of errors and their corrections that were found after the product was released. If the error was corrected in a later version or reprint the date of the correction will be displayed in the column titled "Date Corrected".

The following errata were submitted by our customers and approved as valid errors by the author or editor.

Color key: Serious technical mistake Minor technical mistake Language or formatting error Typo Question Note Update

Version Location Description Submitted By Date submitted Date corrected
Printed
Page viii
-2

more exciting that baseball
->
more exciting than baseball

########################################

 Anonymous    Feb 01, 2007
Printed
Page xi
+1

cutomer
->
customer

########################################

 Anonymous    Feb 01, 2007
Printed
Page xviii
TOC item for page 401

in in
->
in

########################################

 Anonymous    Feb 01, 2007
Printed
Page xix
TOC for page 442

Analsysis
->
Analysis

########################################

 Anonymous    Feb 01, 2007
Printed
Page xxx
+2, line 3

wtih
->
with

########################################

 Anonymous    Feb 01, 2007
Printed
Page xxx
+4, line 2

paramaterized
->
parameterized

########################################

 Anonymous    Feb 01, 2007
Printed
Page back cover
quote at top from Ivar Jacobson

...is a refreshing look at subject of...
->
...is a refreshing look at the subject of...

########################################

 Anonymous    Feb 01, 2007
Printed
Page 3
lower-middle of page

Rick decided these are the definining characters...
->
Rick decided these are the definining characteristics...

########################################

 Anonymous    Feb 01, 2007
Printed
Page 4

The setPrice() method in Guitar should take a double instead of a float. This text shows it as a float, but since we return a double in
getPrice() and use a double in the constructor for a Guitar, using a
float in setPrice() is incorrect.

Anonymous   
Printed
Page 6
code comment

an Fender
->
a Fender

########################################

 Anonymous    Feb 01, 2007
Printed
Page 7
-1

...in the blanks before.
->
...in the blanks below.

########################################

 Anonymous    Feb 01, 2007
Printed
Page 10
last box

...so ypu don't have to...
->
...so you don't have to...

########################################

 Anonymous    Feb 01, 2007
Printed
Page 15
Jill's bubble, second sentence

It looks like in Rick's inventory, he's got "fender", all lowercase, and
the customer's specs have "Fender" with a capital "F".
->
It looks like in Rick's inventory, he's got "Fender" with a capital "F,"
and the customer's specs have "fender" all lowercase.

########################################

 Anonymous    Feb 01, 2007
Printed
Page 28
margin note

Encapsulation allows you to group your application into logical parts.
->
Encapsulation allows you to hide the inner workings of your
application's parts, but yet make it clear what each part does.

########################################

 Anonymous    Feb 01, 2007
Printed
Page 34
header

obejct-oriented
->
object-oriented

########################################

 Anonymous    Feb 01, 2007
Printed
Page 37
lower right margin

See what we said on page 37.
->
See what we said on page 53.

########################################

 Anonymous    Feb 01, 2007
Printed
Page 40
+1

Rick wants to be ble to sell...
->
Rick wants to be able to sell...

########################################

 Anonymous    Feb 01, 2007
Printed
Page 47
last comment

easlly
->
easily

########################################

 Anonymous    Feb 01, 2007
Printed
Page 49
+2, line 4

a customers
->
a customer

########################################

 Anonymous    Feb 01, 2007
Printed
Page 50
3rd bullet point on left

Encapsulation is breaking your application up into logical parts.
->
Encapsulation is separating the specification of what an object can do
from the actual implementation of how the object achieves its goals.

########################################

 Anonymous    Feb 01, 2007
Printed
Page 52
paragraph belonging to Encapsulation, line 2

seperate
->
separate

########################################

 Anonymous    Feb 01, 2007
Printed
Page 55
line 3

cutomer
->
customer

########################################

 Anonymous    Feb 01, 2007
Printed
Page 100
bottom left

Bitsie can't get outside with Kristen letting her out.
->
Bitsie can't get outside without Kristen letting her out.

########################################

 Anonymous    Feb 01, 2007
Printed
Page 128
paths 6-8

6. 1, 2.1, 3.1, 4, 5, 6, 6.1, 6.2, 6.3.1, 6.4.1, 6.5, 7, 8
7. 1, 2, 3, 4, 5, 6, 6.1, 6.2, 6.3, 6.4, 6.5, 7, 8
8. <nothing else>

->

6. 1, 2, 3, 4, 5, 6, 6.1, 6.2, 6.3, 6.4, 6.5, 7, 8
7. <nothing else>
8. <nothing else>

########################################

 Anonymous    Feb 01, 2007
Printed
Page 137
middle left

...decides that he know...
->
...decides that he knows...

########################################

 Anonymous    Feb 01, 2007
Printed
Page 158
comment to Bark class

Randy's Bark class diagram
->
Sam's Bark class diagram

########################################

 Anonymous    Feb 01, 2007
Printed
Page 160
under #2

reconize()
->
recognize()

########################################

 Anonymous    Feb 01, 2007
Printed
Page 172
+1

orignal
->
original

########################################

 Anonymous    Feb 01, 2007
Printed
Page 173
2nd Q on left

sawing
->
saying

########################################

 Anonymous    Feb 01, 2007
Printed
Page 173
2nd A on left

embarassing
->
embarrassing

########################################

 Anonymous    Feb 01, 2007
Printed
Page 186
+7 (Maria)

somewhow
->
somehow

########################################

 Anonymous    Feb 01, 2007
Printed
Page 187
last subtitle

sytem
->
system

########################################

 Anonymous    Feb 01, 2007
Printed
Page 188
comment to BarkRecognizer

bards
->
barks

########################################

 Anonymous    Feb 01, 2007
Printed
Page 194
+1

defintions
->
definitions

########################################

 Anonymous    Feb 01, 2007
Printed
Page 196
+1

defintions
->
definitions

########################################

 Anonymous    Feb 01, 2007
Printed
Page 196
bottom half excercise solution

Attribute and operation are mixed up; attribute incorrectly points to
the method, and operation incorrectly points to the member variable.
->
Attribute now points to the member variable and operation to the method.

########################################

 Anonymous    Feb 01, 2007
Printed
Page 203
first A, line 2

things
->
thing

########################################

 Anonymous    Feb 01, 2007
Printed
Page 208
+1

We can start off be creating...
->
We can start off by creating...

########################################

 Anonymous    Feb 01, 2007
Printed
Page 216
3rd answer, line 3

rememeber
->
remember

########################################

 Anonymous    Feb 01, 2007
Printed
Page 224
-1

Athelete
->
Athlete

########################################

 Anonymous    Feb 01, 2007
Printed
Page 227
figure

it has only one reason to this
->
it has only one reason to do this

########################################

 Anonymous    Feb 01, 2007
Printed
Page 248
-3

proeprties
->
properties

########################################

 Anonymous    Feb 01, 2007
Printed
Page 250
1st diagram, 1st comment

a Map to stores all properties.
->
a Map to store all properties.

########################################

 Anonymous    Feb 01, 2007
Printed
Page 269
2nd note on left side of page

it might belong on another class
->
it might belong in another class

########################################

 Anonymous    Feb 01, 2007
Printed
Page 270
figure

it has only one reason to this
->
it has only one reason to do this

########################################

 Anonymous    Feb 01, 2007
Printed
Page 272
note in top right corner of page

suport
->
support

########################################

 Anonymous    Feb 01, 2007
Printed
Page 289
-3 (Bethany)

designeres
->
designers

########################################

 Anonymous    Feb 01, 2007
Printed
Page 292
last word

bulding
->
building

########################################

 Anonymous    Feb 01, 2007
Printed
Page 297
+1, line 4

fundametal
->
fundamental

########################################

 Anonymous    Feb 01, 2007
Printed
Page 299
1st A in right column

kind
->
kinds

########################################

 Anonymous    Feb 01, 2007
Printed
Page 321
description, line 3

sqaures
->
squares

########################################

 Anonymous    Feb 01, 2007
Printed
Page 345
1st Q

Architecure
->
Architecture

########################################

 Anonymous    Feb 01, 2007
Printed
Page 345
last Q

unneccessary
->
unnecessary

########################################

 Anonymous    Feb 01, 2007
Printed
Page 350
+2

stucture
->
structure

########################################

 Anonymous    Feb 01, 2007
Printed
Page 360
comment at end of page

proeprty
->
property

########################################

 Anonymous    Feb 01, 2007
Printed
Page 372
-2

commmonality
->
commonality

########################################

 Anonymous    Feb 01, 2007
Printed
Page 376
+2

principle
->
principles

########################################

 Anonymous    Feb 01, 2007
Printed
Page 391
1st A in 2nd column

programers
->
programmers

########################################

 Anonymous    Feb 01, 2007
Printed
Page 392
+3

responsiblity
->
responsibility

########################################

 Anonymous    Feb 01, 2007
Printed
Page 417
-2 in 2nd column

ot
->
to

########################################

 Anonymous    Feb 01, 2007
Printed
Page 430
-1 (under "Use case driven development")


particuarly
->
particularly

########################################

(430, 5th line of comment to "Use case driven development"

since a single a
->
since a single

########################################

 Anonymous    Feb 01, 2007
Printed
Page 438
right-most comment on second console

retreiving
->
retrieving

########################################

 Anonymous    Feb 01, 2007
Printed
Page 439
+1

liks
->
like

########################################

 Anonymous    Feb 01, 2007
Printed
Page 445
right column, third line from end

variablity
->
variability

########################################

 Anonymous    Feb 01, 2007
Printed
Page 470
2nd A, line 2

reuired
->
required

########################################

 Anonymous    Feb 01, 2007
Printed
Page 477
comment on UnitGroups, last line

IUnitGroup
->
UnitGroup

########################################

 Anonymous    Feb 01, 2007
Printed
Page 508
2nd A, line 4

mispells
->
misspells

########################################

 Anonymous    Feb 01, 2007
Printed
Page 563
big note on Anti patterns

reconizing
->
recognizing

########################################

 Anonymous    Feb 01, 2007
Printed
Page 566
+2

(and also depends on lot on how...
->
(and also depends a lot on how...

########################################

 Anonymous    Feb 01, 2007
Printed
Page 568
+1, last line

descrbing
->
describing

########################################

 Anonymous    Feb 01, 2007
Printed
Page 568
+2, line 5

desgners
->
designers

########################################

 Anonymous    Feb 01, 2007
Printed
Page 574
+1, line 3

cleaness
->
cleanness

########################################

 Anonymous    Feb 01, 2007
Printed
Page 574
-1, last line

your code will think you for it.
->
your code will thank you for it.

########################################

 Anonymous    Feb 01, 2007
Printed
Page 582
+1

Encapsulation is when you hide parts of your data from the rest of your
application, and limit the ability for other parts of your code to access
that data. Suppose we rewrote our Airplane class like this:
->
Encapsulation is when you hide the implementation of a class in such a
way that it is easy to use and easy to change. It makes the class act
as a black box that provides a service to its users, but does not open
up the code so someone can change it or use it the wrong way.
Encapsulation is a key technique in being able to follow the Open-Closed
principle. Suppose we rewrote our Airplane class like this:

########################################

 Anonymous    Feb 01, 2007
Printed
Page 584
1st longhand answer in "sharpen your pencil" solution

multiples it by two
->
multiplies it by two

########################################

 Anonymous    Feb 01, 2007
Printed
Page 587
+1

Even though this is Chapter 0, here's Crossword #1. Take a moment to review
the concepts in this chapter.
->
Take a moment to review the concepts in this chapter.

########################################

 Anonymous    Feb 01, 2007