Errata for Refactoring
Here are the current known errors in the Refactoring book.
Errors in 24th and later printings
Page 12:
I've been asked for more information about the double to int rounding. It happens when you have a compound assignment. In other words
int foo=1; foo += 1.5;
compiles, as it is equivalent to
int foo = 1; foo = (int) (foo + 1.5);
I haven't looked into the rationale behind this. (see Java Language Specification, section 15.26.2)
(Not fixable in reprints.)
Page 148:
In the top code example, the line
private double _interestRate
should read
private double _interestRate
as that code is removed at this point.
Page 166:
in the sixth code example, the line
class mfDate {
should read
class MfDateWrap {
Page 166:
In the fifth code example, the line
class MfDate…
should read
class MfDateSub…
Page 167:
in the fourth code example, the line
class MfDate…
should read
class MfDateWrap…
Page 258:
In the first code example the line
return Employee.ENGINEER;
should be
return EmployeeType.ENGINEER;
Page 301:
There are problems with the example, see the discussion in Remove Setting Method.
(Not fixable in reprints.)
Page 316:
In the first paragraph of the example, the text “When a client wants a resource, the pool hands it out…” should read “When a client wants a resource, the manager hands it out ...”
Page 324:
In the first code example the line
void createBill(date Date) {
should read
void createBill(Date date) {
Page 351: In the UML Diagram, the relationship between Customer and Statement should be a dependency, not an association.
Page 366:
The first reference to figure 12.6 should actually refer to figure 12.5
Errors in the 16th thru 24th printing
Page 12:
I've been asked for more information about the double to int rounding. It happens when you have a compound assignment. In other words
int foo=1; foo += 1.5;
compiles, as it is equivalent to
int foo = 1; foo = (int) (foo + 1.5);
I haven't looked into the rationale behind this. (see Java Language Specification, section 15.26.2)
(Not fixable in reprints.)
Page 119: At the start of the mechanics add a step: “check that the right hand side of the assignment is free of side-effects”. [Corrected in the 24th printing]
Page 148:
In the top code example, the line
private double _interestRate
should read
private double _interestRate
as that code is removed at this point.
Page 165: The second to last code sample is incorrect, it should read as follows.
class MfDateSub extends Date {
public MfDateSub nextDay()...
public int dayOfYear()...
[Corrected in the 24th printing]
Page 165: In the final code sample class mfDate
should read class MfDateWrap [Corrected in the 24th printing]
Page 166: In the second to last code sample class
mfDate should read class MfDateWrap [Corrected in the 24th printing]
Page 166:
in the sixth code example, the line
class mfDate {
should read
class MfDateWrap {
Page 166:
In the fifth code example, the line
class MfDate…
should read
class MfDateSub…
Page 167: About a third of the way down, the equals method is incorrect. It should read
public boolean equals(Object arg) {
if (this == arg) return true;
if (! (arg instanceof MfDateWrap)) return false;
MfDateWrap other = ((MfDateWrap) arg);
return (_original.equals(other._original));
}
[Corrected in the 24th printing]
Page 167:
in the fourth code example, the line
class MfDate…
should read
class MfDateWrap…
Page 258:
In the first code example the line
return Employee.ENGINEER;
should be
return EmployeeType.ENGINEER;
Page 301:
There are problems with the example, see the discussion in Remove Setting Method.
(Not fixable in reprints.)
Page 316:
In the first paragraph of the example, the text “When a client wants a resource, the pool hands it out…” should read “When a client wants a resource, the manager hands it out ...”
Page 324:
In the first code example the line
void createBill(date Date) {
should read
void createBill(Date date) {
Page 351: In the UML Diagram, the relationship between Customer and Statement should be a dependency, not an association.
Page 366:
The first reference to figure 12.6 should actually refer to figure 12.5
Errors in the 15th printing
Page 12:
I've been asked for more information about the double to int rounding. It happens when you have a compound assignment. In other words
int foo=1; foo += 1.5;
compiles, as it is equivalent to
int foo = 1; foo = (int) (foo + 1.5);
I haven't looked into the rationale behind this. (see Java Language Specification, section 15.26.2)
(Not fixable in reprints.)
Page 119: At the start of the mechanics add a step: “check that the right hand side of the assignment is free of side-effects”. [Corrected in the 24th printing]
Page 148:
In the top code example, the line
private double _interestRate
should read
private double _interestRate
as that code is removed at this point.
Page 153: In the second para, third line “As discussed in Lea by section...” should read “As discussed in Lea in section....” [Corrected in the 16th printing]
Page 165: The second to last code sample is incorrect, it should read as follows.
class MfDateSub extends Date {
public MfDateSub nextDay()...
public int dayOfYear()...
[Corrected in the 24th printing]
Page 165: In the final code sample class mfDate
should read class MfDateWrap [Corrected in the 24th printing]
Page 166: In the second to last code sample class
mfDate should read class MfDateWrap [Corrected in the 24th printing]
Page 166:
in the sixth code example, the line
class mfDate {
should read
class MfDateWrap {
Page 166:
In the fifth code example, the line
class MfDate…
should read
class MfDateSub…
Page 167: About a third of the way down, the equals method is incorrect. It should read
public boolean equals(Object arg) {
if (this == arg) return true;
if (! (arg instanceof MfDateWrap)) return false;
MfDateWrap other = ((MfDateWrap) arg);
return (_original.equals(other._original));
}
[Corrected in the 24th printing]
Page 167:
in the fourth code example, the line
class MfDate…
should read
class MfDateWrap…
Page 222:
At the bottom of the page I make the method getCode
private. I obviously can't do that while any clients of BloodGroup
are using the method. As a result the sentance “I can also privatize
the methods...”, should begin “If no clients use the numeric code I
can also privatize the methods...”
[Corrected in the 16th printing]
Page 258:
In the first code example the line
return Employee.ENGINEER;
should be
return EmployeeType.ENGINEER;
Page 301:
There are problems with the example, see the discussion in Remove Setting Method.
(Not fixable in reprints.)
Page 316:
In the first paragraph of the example, the text “When a client wants a resource, the pool hands it out…” should read “When a client wants a resource, the manager hands it out ...”
Page 324:
In the first code example the line
void createBill(date Date) {
should read
void createBill(Date date) {
Page 351: In the UML Diagram, the relationship between Customer and Statement should be a dependency, not an association.
Page 366:
The first reference to figure 12.6 should actually refer to figure 12.5
Errors in the 13th thru 15th printing
Page 12:
I've been asked for more information about the double to int rounding. It happens when you have a compound assignment. In other words
int foo=1; foo += 1.5;
compiles, as it is equivalent to
int foo = 1; foo = (int) (foo + 1.5);
I haven't looked into the rationale behind this. (see Java Language Specification, section 15.26.2)
(Not fixable in reprints.)
Page 83: In the Speculative Generality section, first paragraph, second sentence. “Oh, I think we need the ability to this...” should read “Oh, I think we need the ability to do this...”. [Corrected in the 15th printing]
Page 98:
The method testReadAtEnd is incorrect. I looked at my
source files and found the method there to say
public
void testReadAtEnd() throws IOException {
int ch = -1234;
for (int i = 0; i < 141; i++)
ch = _input.read();
assertEquals("read at end", -1, _input.read());
}
Another reason to be glad that these days I'm auto-inserting source code!
[Corrected in the 15th printing]
Page 115: In the third line, “rerun” should be “return” [Corrected in the 15th printing]
Page 119: At the start of the mechanics add a step: “check that the right hand side of the assignment is free of side-effects”. [Corrected in the 24th printing]
Page 120: Last line, “...assigned only to once...” should read “...only assigned to once...” [Corrected in the 15th printing]
Page 120: In the solution statement the phrase “Replace all references to the temp with the expression” should be replaced with “Replace all references to the temp with the new method” [Corrected in the 15th printing]
Page 128: In the first paragraph of the motivation the expression “for (int i=0; i<10; i++) needs an extra parenthesis to balance the earlier textual one. [Corrected in the 15th printing]
Page 148:
In the top code example, the line
private double _interestRate
should read
private double _interestRate
as that code is removed at this point.
Page 153: In the second para, third line “As discussed in Lea by section...” should read “As discussed in Lea in section....” [Corrected in the 16th printing]
Page 165: The second to last code sample is incorrect, it should read as follows.
class MfDateSub extends Date {
public MfDateSub nextDay()...
public int dayOfYear()...
[Corrected in the 24th printing]
Page 165: In the final code sample class mfDate
should read class MfDateWrap [Corrected in the 24th printing]
Page 166: In the second to last code sample class
mfDate should read class MfDateWrap [Corrected in the 24th printing]
Page 166:
in the sixth code example, the line
class mfDate {
should read
class MfDateWrap {
Page 166:
In the fifth code example, the line
class MfDate…
should read
class MfDateSub…
Page 167: About a third of the way down, the equals method is incorrect. It should read
public boolean equals(Object arg) {
if (this == arg) return true;
if (! (arg instanceof MfDateWrap)) return false;
MfDateWrap other = ((MfDateWrap) arg);
return (_original.equals(other._original));
}
[Corrected in the 24th printing]
Page 167:
in the fourth code example, the line
class MfDate…
should read
class MfDateWrap…
Page 176: In the second para, (a step in the mechanics) “change the getting method” should read “change the setting method” [Corrected in the 15th printing]
Page 222:
At the bottom of the page I make the method getCode
private. I obviously can't do that while any clients of BloodGroup
are using the method. As a result the sentance “I can also privatize
the methods...”, should begin “If no clients use the numeric code I
can also privatize the methods...”
[Corrected in the 16th printing]
Page 258:
In the first code example the line
return Employee.ENGINEER;
should be
return EmployeeType.ENGINEER;
Page 301:
There are problems with the example, see the discussion in Remove Setting Method.
(Not fixable in reprints.)
Page 316:
In the first paragraph of the example, the text “When a client wants a resource, the pool hands it out…” should read “When a client wants a resource, the manager hands it out ...”
Page 324:
In the first code example the line
void createBill(date Date) {
should read
void createBill(Date date) {
Page 349: The first paragraph should end with a close parenthesis to match the one of the first line. [Corrected in the 15th printing]
Page 351: In the UML Diagram, the relationship between Customer and Statement should be a dependency, not an association.
Page 366:
The first reference to figure 12.6 should actually refer to figure 12.5
Errors in the 12th printing
Page 12:
I've been asked for more information about the double to int rounding. It happens when you have a compound assignment. In other words
int foo=1; foo += 1.5;
compiles, as it is equivalent to
int foo = 1; foo = (int) (foo + 1.5);
I haven't looked into the rationale behind this. (see Java Language Specification, section 15.26.2)
(Not fixable in reprints.)
Page 83: In the Speculative Generality section, first paragraph, second sentence. “Oh, I think we need the ability to this...” should read “Oh, I think we need the ability to do this...”. [Corrected in the 15th printing]
Page 98:
The method testReadAtEnd is incorrect. I looked at my
source files and found the method there to say
public
void testReadAtEnd() throws IOException {
int ch = -1234;
for (int i = 0; i < 141; i++)
ch = _input.read();
assertEquals("read at end", -1, _input.read());
}
Another reason to be glad that these days I'm auto-inserting source code!
[Corrected in the 15th printing]
Page 115: In the third line, “rerun” should be “return” [Corrected in the 15th printing]
Page 119: At the start of the mechanics add a step: “check that the right hand side of the assignment is free of side-effects”. [Corrected in the 24th printing]
Page 120: Last line, “...assigned only to once...” should read “...only assigned to once...” [Corrected in the 15th printing]
Page 120: In the solution statement the phrase “Replace all references to the temp with the expression” should be replaced with “Replace all references to the temp with the new method” [Corrected in the 15th printing]
Page 121: This was an incorrect fix to an earlier error. In the last line of the mechanics the refactoring 'Replace Temp with Inline Temp' should read 'Inline Temp'. The same problem occurs on page 122. [Corrected in the 13th printing]
Page 128: In the first paragraph of the motivation the expression “for (int i=0; i<10; i++) needs an extra parenthesis to balance the earlier textual one. [Corrected in the 15th printing]
Page 148:
In the top code example, the line
private double _interestRate
should read
private double _interestRate
as that code is removed at this point.
Page 153: In the second para, third line “As discussed in Lea by section...” should read “As discussed in Lea in section....” [Corrected in the 16th printing]
Page 165: The second to last code sample is incorrect, it should read as follows.
class MfDateSub extends Date {
public MfDateSub nextDay()...
public int dayOfYear()...
[Corrected in the 24th printing]
Page 165: In the final code sample class mfDate
should read class MfDateWrap [Corrected in the 24th printing]
Page 166: In the second to last code sample class
mfDate should read class MfDateWrap [Corrected in the 24th printing]
Page 166:
in the sixth code example, the line
class mfDate {
should read
class MfDateWrap {
Page 166:
In the fifth code example, the line
class MfDate…
should read
class MfDateSub…
Page 167: About a third of the way down, the equals method is incorrect. It should read
public boolean equals(Object arg) {
if (this == arg) return true;
if (! (arg instanceof MfDateWrap)) return false;
MfDateWrap other = ((MfDateWrap) arg);
return (_original.equals(other._original));
}
[Corrected in the 24th printing]
Page 167:
in the fourth code example, the line
class MfDate…
should read
class MfDateWrap…
Page 176: In the second para, (a step in the mechanics) “change the getting method” should read “change the setting method” [Corrected in the 15th printing]
Page 222:
At the bottom of the page I make the method getCode
private. I obviously can't do that while any clients of BloodGroup
are using the method. As a result the sentance “I can also privatize
the methods...”, should begin “If no clients use the numeric code I
can also privatize the methods...”
[Corrected in the 16th printing]
Page 225:
The first mention of the create method is missing the
static keyword.
[Corrected in the 13th printing]
Page 258:
In the first code example the line
return Employee.ENGINEER;
should be
return EmployeeType.ENGINEER;
Page 301:
There are problems with the example, see the discussion in Remove Setting Method.
(Not fixable in reprints.)
Page 316:
In the first paragraph of the example, the text “When a client wants a resource, the pool hands it out…” should read “When a client wants a resource, the manager hands it out ...”
Page 324:
In the first code example the line
void createBill(date Date) {
should read
void createBill(Date date) {
Page 349: The first paragraph should end with a close parenthesis to match the one of the first line. [Corrected in the 15th printing]
Page 351: In the UML Diagram, the relationship between Customer and Statement should be a dependency, not an association.
Page 363: The references to the refactorings on this page are cross referenced with chapter references rather than the usual page references. Worse still, the chapter for Extract Class should be Chapter 7. [Corrected in the 13th printing]
Page 366:
The first reference to figure 12.6 should actually refer to figure 12.5
Errors in the 8th thru 12th printing
Page 2: In the first paragraph “and identifies the type movie” should read “and identifies the type of movie”. [Corrected in the 12th printing]
Page 12:
I've been asked for more information about the double to int rounding. It happens when you have a compound assignment. In other words
int foo=1; foo += 1.5;
compiles, as it is equivalent to
int foo = 1; foo = (int) (foo + 1.5);
I haven't looked into the rationale behind this. (see Java Language Specification, section 15.26.2)
(Not fixable in reprints.)
Page 40: In the code examples on pages 40 and 41 the
references to the field _name should instead be
_title [Corrected in the 12th printing]
Page 83: In the Speculative Generality section, first paragraph, second sentence. “Oh, I think we need the ability to this...” should read “Oh, I think we need the ability to do this...”. [Corrected in the 15th printing]
Page 98:
The method testReadAtEnd is incorrect. I looked at my
source files and found the method there to say
public
void testReadAtEnd() throws IOException {
int ch = -1234;
for (int i = 0; i < 141; i++)
ch = _input.read();
assertEquals("read at end", -1, _input.read());
}
Another reason to be glad that these days I'm auto-inserting source code!
[Corrected in the 15th printing]
Page 115: In the third line, “rerun” should be “return” [Corrected in the 15th printing]
Page 119: At the start of the mechanics add a step: “check that the right hand side of the assignment is free of side-effects”. [Corrected in the 24th printing]
Page 120: Last line, “...assigned only to once...” should read “...only assigned to once...” [Corrected in the 15th printing]
Page 120: In the solution statement the phrase “Replace all references to the temp with the expression” should be replaced with “Replace all references to the temp with the new method” [Corrected in the 15th printing]
Page 121: This was an incorrect fix to an earlier error. In the last line of the mechanics the refactoring 'Replace Temp with Inline Temp' should read 'Inline Temp'. The same problem occurs on page 122. [Corrected in the 13th printing]
Page 128: In the first paragraph of the motivation the expression “for (int i=0; i<10; i++) needs an extra parenthesis to balance the earlier textual one. [Corrected in the 15th printing]
Page 148:
In the top code example, the line
private double _interestRate
should read
private double _interestRate
as that code is removed at this point.
Page 153: In the second para, third line “As discussed in Lea by section...” should read “As discussed in Lea in section....” [Corrected in the 16th printing]
Page 165: The second to last code sample is incorrect, it should read as follows.
class MfDateSub extends Date {
public MfDateSub nextDay()...
public int dayOfYear()...
[Corrected in the 24th printing]
Page 165: In the final code sample class mfDate
should read class MfDateWrap [Corrected in the 24th printing]
Page 166: In the second to last code sample class
mfDate should read class MfDateWrap [Corrected in the 24th printing]
Page 166:
in the sixth code example, the line
class mfDate {
should read
class MfDateWrap {
Page 166:
In the fifth code example, the line
class MfDate…
should read
class MfDateSub…
Page 167: About a third of the way down, the equals method is incorrect. It should read
public boolean equals(Object arg) {
if (this == arg) return true;
if (! (arg instanceof MfDateWrap)) return false;
MfDateWrap other = ((MfDateWrap) arg);
return (_original.equals(other._original));
}
[Corrected in the 24th printing]
Page 167:
in the fourth code example, the line
class MfDate…
should read
class MfDateWrap…
Page 176: In the second para, (a step in the mechanics) “change the getting method” should read “change the setting method” [Corrected in the 15th printing]
Page 185: In the second paragraph “biwise xor” shoudl read “bitwise xor” [Corrected in the 12th printing]
Page 222:
At the bottom of the page I make the method getCode
private. I obviously can't do that while any clients of BloodGroup
are using the method. As a result the sentance “I can also privatize
the methods...”, should begin “If no clients use the numeric code I
can also privatize the methods...”
[Corrected in the 16th printing]
Page 225:
The first mention of the create method is missing the
static keyword.
[Corrected in the 13th printing]
Page 258:
In the first code example the line
return Employee.ENGINEER;
should be
return EmployeeType.ENGINEER;
Page 301:
There are problems with the example, see the discussion in Remove Setting Method.
(Not fixable in reprints.)
Page 316:
In the first paragraph of the example, the text “When a client wants a resource, the pool hands it out…” should read “When a client wants a resource, the manager hands it out ...”
Page 324:
In the first code example the line
void createBill(date Date) {
should read
void createBill(Date date) {
Page 349: The first paragraph should end with a close parenthesis to match the one of the first line. [Corrected in the 15th printing]
Page 351: In the UML Diagram, the relationship between Customer and Statement should be a dependency, not an association.
Page 363: The references to the refactorings on this page are cross referenced with chapter references rather than the usual page references. Worse still, the chapter for Extract Class should be Chapter 7. [Corrected in the 13th printing]
Page 366:
The first reference to figure 12.6 should actually refer to figure 12.5
Errors in the 5th thru 8th printing
Page 2: In the first paragraph “and identifies the type movie” should read “and identifies the type of movie”. [Corrected in the 12th printing]
Page 12:
I've been asked for more information about the double to int rounding. It happens when you have a compound assignment. In other words
int foo=1; foo += 1.5;
compiles, as it is equivalent to
int foo = 1; foo = (int) (foo + 1.5);
I haven't looked into the rationale behind this. (see Java Language Specification, section 15.26.2)
(Not fixable in reprints.)
Page 25: Caption on fig 1.7 “Sequence diagram before extraction...” should be “Sequence diagram after extraction...” [Corrected in the 8th printing]
Page 40: In the code examples on pages 40 and 41 the
references to the field _name should instead be
_title [Corrected in the 12th printing]
Page 76: 3rd para in “Duplicated Code”. “in both classes then Pull Up Field (320)” should read “in both classes then Pull Up Method (322)” [Corrected in the 8th printing]
Page 83: In the Speculative Generality section, first paragraph, second sentence. “Oh, I think we need the ability to this...” should read “Oh, I think we need the ability to do this...”. [Corrected in the 15th printing]
Page 98:
The method testReadAtEnd is incorrect. I looked at my
source files and found the method there to say
public
void testReadAtEnd() throws IOException {
int ch = -1234;
for (int i = 0; i < 141; i++)
ch = _input.read();
assertEquals("read at end", -1, _input.read());
}
Another reason to be glad that these days I'm auto-inserting source code!
[Corrected in the 15th printing]
Page 115: In the third line, “rerun” should be “return” [Corrected in the 15th printing]
Page 119: At the start of the mechanics add a step: “check that the right hand side of the assignment is free of side-effects”. [Corrected in the 24th printing]
Page 120: Last line, “...assigned only to once...” should read “...only assigned to once...” [Corrected in the 15th printing]
Page 120: In the solution statement the phrase “Replace all references to the temp with the expression” should be replaced with “Replace all references to the temp with the new method” [Corrected in the 15th printing]
Page 121: In the last step of the mechanics, I say to use Replace Temp with Query (120), this should be replaced with a reference to Inline Temp (119). Otherwise I'd get a recursive refactoring. The problem continues in the example on page 122 where again the cross reference should be to Inline Temp (119). This was fixed incorrectly in the 8th printing (see below) [Corrected in the 8th printing]
Page 121: This was an incorrect fix to an earlier error. In the last line of the mechanics the refactoring 'Replace Temp with Inline Temp' should read 'Inline Temp'. The same problem occurs on page 122. [Corrected in the 13th printing]
Page 128: In the first paragraph of the motivation the expression “for (int i=0; i<10; i++) needs an extra parenthesis to balance the earlier textual one. [Corrected in the 15th printing]
Page 148:
In the top code example, the line
private double _interestRate
should read
private double _interestRate
as that code is removed at this point.
Page 153: In the second para, third line “As discussed in Lea by section...” should read “As discussed in Lea in section....” [Corrected in the 16th printing]
Page 165: The second to last code sample is incorrect, it should read as follows.
class MfDateSub extends Date {
public MfDateSub nextDay()...
public int dayOfYear()...
[Corrected in the 24th printing]
Page 165: In the final code sample class mfDate
should read class MfDateWrap [Corrected in the 24th printing]
Page 166: In the second to last code sample class
mfDate should read class MfDateWrap [Corrected in the 24th printing]
Page 166:
in the sixth code example, the line
class mfDate {
should read
class MfDateWrap {
Page 166:
In the fifth code example, the line
class MfDate…
should read
class MfDateSub…
Page 167: About a third of the way down, the equals method is incorrect. It should read
public boolean equals(Object arg) {
if (this == arg) return true;
if (! (arg instanceof MfDateWrap)) return false;
MfDateWrap other = ((MfDateWrap) arg);
return (_original.equals(other._original));
}
[Corrected in the 24th printing]
Page 167:
in the fourth code example, the line
class MfDate…
should read
class MfDateWrap…
Page 176: In the second para, (a step in the mechanics) “change the getting method” should read “change the setting method” [Corrected in the 15th printing]
Page 176:
In the method numberOfOrdersFor the line that reads
if (each.getCustomerName().equals(customer)) result++;
should read if (each.getCustomer().equals(customer))
result++; [Corrected in the 8th printing]
Page 177:
In the first state of the method setCustomer the line
that reads _customer = new Customer (customer); should
read _customer = new Customer (arg); [Corrected in the 8th printing]
Page 185: In the second paragraph “biwise xor” shoudl read “bitwise xor” [Corrected in the 12th printing]
Page 219: “In a paragraph at around the middle of page, the sentence “...need a new method that returns the code” should read “...need a new method that returns an instance of the new class.” [Corrected in the 8th printing]
Page 222:
At the bottom of the page I make the method getCode
private. I obviously can't do that while any clients of BloodGroup
are using the method. As a result the sentance “I can also privatize
the methods...”, should begin “If no clients use the numeric code I
can also privatize the methods...”
[Corrected in the 16th printing]
Page 222:
“In the crossed out code, the method “public int
getBloodGroup() {” should be “public int
getBloodGroupCode() {” (I had just renamed it!)”
[Corrected in the 8th printing]
Page 225:
The first mention of the create method is missing the
static keyword.
[Corrected in the 13th printing]
Page 258:
In the first code example the line
return Employee.ENGINEER;
should be
return EmployeeType.ENGINEER;
Page 285: The before code contains a rather more serious error than the refactoring is meant to help with as the assertion is always executed. The before code should read:
void setValue (String name, int value) {
if (name.equals(“height”)) {
_height = value;
return;
}
if (name.equals(“width”)) {
_width = value;
return;
}
Assert.shouldNeverReachHere();
}
[Corrected in the 8th printing]
Page 301:
There are problems with the example, see the discussion in Remove Setting Method.
(Not fixable in reprints.)
Page 313:
The line of code that says
Assert.isTrue(“amount too large”, amount > _balance);
is in error as the sense of the boolean is the wrong way round. A better line would be
Assert.isTrue(“sufficient funds”, amount <= _balance);[Corrected in the 8th printing]
Page 316:
In the first paragraph of the example, the text “When a client wants a resource, the pool hands it out…” should read “When a client wants a resource, the manager hands it out ...”
Page 324:
In the first code example the line
void createBill(date Date) {
should read
void createBill(Date date) {
Page 324:
In the top code example the line double chargeAmount = charge
(lastBillDate, date) should read double chargeAmount =
chargeFor (lastBillDate, date). (I got the method name
inconsistent with the diagrams.)
[Corrected in the 8th printing]
Page 328: In the motivation paragraph “Pull Down Method” should read “Push Down Method”. (This is what happens when I don't use links for everything!) [Corrected in the 8th printing]
Page 349: The first paragraph should end with a close parenthesis to match the one of the first line. [Corrected in the 15th printing]
Page 351: In the UML Diagram, the relationship between Customer and Statement should be a dependency, not an association.
Page 363: The references to the refactorings on this page are cross referenced with chapter references rather than the usual page references. Worse still, the chapter for Extract Class should be Chapter 7. [Corrected in the 13th printing]
Page 366:
The first reference to figure 12.6 should actually refer to figure 12.5
Errors in the 4th printing
Page xx: “Joshua suggested the idea of code sketches” should read “Joshua Kerievsky suggested the idea of code sketches” [Corrected in the 5th printing]
Page 2: In the first paragraph “and identifies the type movie” should read “and identifies the type of movie”. [Corrected in the 12th printing]
Page 12:
I've been asked for more information about the double to int rounding. It happens when you have a compound assignment. In other words
int foo=1; foo += 1.5;
compiles, as it is equivalent to
int foo = 1; foo = (int) (foo + 1.5);
I haven't looked into the rationale behind this. (see Java Language Specification, section 15.26.2)
(Not fixable in reprints.)
Page 25: Caption on fig 1.7 “Sequence diagram before extraction...” should be “Sequence diagram after extraction...” [Corrected in the 8th printing]
Page 40: In the code examples on pages 40 and 41 the
references to the field _name should instead be
_title [Corrected in the 12th printing]
Page 76: 3rd para in “Duplicated Code”. “in both classes then Pull Up Field (320)” should read “in both classes then Pull Up Method (322)” [Corrected in the 8th printing]
Page 83: In the Speculative Generality section, first paragraph, second sentence. “Oh, I think we need the ability to this...” should read “Oh, I think we need the ability to do this...”. [Corrected in the 15th printing]
Page 98:
The method testReadAtEnd is incorrect. I looked at my
source files and found the method there to say
public
void testReadAtEnd() throws IOException {
int ch = -1234;
for (int i = 0; i < 141; i++)
ch = _input.read();
assertEquals("read at end", -1, _input.read());
}
Another reason to be glad that these days I'm auto-inserting source code!
[Corrected in the 15th printing]
Page 115: In the third line, “rerun” should be “return” [Corrected in the 15th printing]
Page 119: At the start of the mechanics add a step: “check that the right hand side of the assignment is free of side-effects”. [Corrected in the 24th printing]
Page 120: Last line, “...assigned only to once...” should read “...only assigned to once...” [Corrected in the 15th printing]
Page 120: In the solution statement the phrase “Replace all references to the temp with the expression” should be replaced with “Replace all references to the temp with the new method” [Corrected in the 15th printing]
Page 121: In the last step of the mechanics, I say to use Replace Temp with Query (120), this should be replaced with a reference to Inline Temp (119). Otherwise I'd get a recursive refactoring. The problem continues in the example on page 122 where again the cross reference should be to Inline Temp (119). This was fixed incorrectly in the 8th printing (see below) [Corrected in the 8th printing]
Page 121: This was an incorrect fix to an earlier error. In the last line of the mechanics the refactoring 'Replace Temp with Inline Temp' should read 'Inline Temp'. The same problem occurs on page 122. [Corrected in the 13th printing]
Page 128: In the first paragraph of the motivation the expression “for (int i=0; i<10; i++) needs an extra parenthesis to balance the earlier textual one. [Corrected in the 15th printing]
Page 148:
In the top code example, the line
private double _interestRate
should read
private double _interestRate
as that code is removed at this point.
Page 153: In the second para, third line “As discussed in Lea by section...” should read “As discussed in Lea in section....” [Corrected in the 16th printing]
Page 165: The second to last code sample is incorrect, it should read as follows.
class MfDateSub extends Date {
public MfDateSub nextDay()...
public int dayOfYear()...
[Corrected in the 24th printing]
Page 165: In the final code sample class mfDate
should read class MfDateWrap [Corrected in the 24th printing]
Page 166: In the second to last code sample class
mfDate should read class MfDateWrap [Corrected in the 24th printing]
Page 166:
in the sixth code example, the line
class mfDate {
should read
class MfDateWrap {
Page 166:
In the fifth code example, the line
class MfDate…
should read
class MfDateSub…
Page 167: About a third of the way down, the equals method is incorrect. It should read
public boolean equals(Object arg) {
if (this == arg) return true;
if (! (arg instanceof MfDateWrap)) return false;
MfDateWrap other = ((MfDateWrap) arg);
return (_original.equals(other._original));
}
[Corrected in the 24th printing]
Page 167:
in the fourth code example, the line
class MfDate…
should read
class MfDateWrap…
Page 176: In the second para, (a step in the mechanics) “change the getting method” should read “change the setting method” [Corrected in the 15th printing]
Page 176:
In the method numberOfOrdersFor the line that reads
if (each.getCustomerName().equals(customer)) result++;
should read if (each.getCustomer().equals(customer))
result++; [Corrected in the 8th printing]
Page 177:
In the first state of the method setCustomer the line
that reads _customer = new Customer (customer); should
read _customer = new Customer (arg); [Corrected in the 8th printing]
Page 185: In the second paragraph “biwise xor” shoudl read “bitwise xor” [Corrected in the 12th printing]
Page 193: “to declare that interval window implements Observable” should read “to declare that interval window implements Observer“ [Corrected in the 5th printing]
Page 219: “In a paragraph at around the middle of page, the sentence “...need a new method that returns the code” should read “...need a new method that returns an instance of the new class.” [Corrected in the 8th printing]
Page 222:
At the bottom of the page I make the method getCode
private. I obviously can't do that while any clients of BloodGroup
are using the method. As a result the sentance “I can also privatize
the methods...”, should begin “If no clients use the numeric code I
can also privatize the methods...”
[Corrected in the 16th printing]
Page 222:
“In the crossed out code, the method “public int
getBloodGroup() {” should be “public int
getBloodGroupCode() {” (I had just renamed it!)”
[Corrected in the 8th printing]
Page 225:
The first mention of the create method is missing the
static keyword.
[Corrected in the 13th printing]
Page 258:
In the first code example the line
return Employee.ENGINEER;
should be
return EmployeeType.ENGINEER;
Page 261: In Ron's story, 4th para, “Of course, as soon as you being inspecting...” but should be “Of course, as soon as you begin inspecting...” [Corrected in the 5th printing]
Page 285: The before code contains a rather more serious error than the refactoring is meant to help with as the assertion is always executed. The before code should read:
void setValue (String name, int value) {
if (name.equals(“height”)) {
_height = value;
return;
}
if (name.equals(“width”)) {
_width = value;
return;
}
Assert.shouldNeverReachHere();
}
[Corrected in the 8th printing]
Page 300: In the mechanics section the field should be made final at the end of process not at the begining. [Corrected in the 5th printing]
Page 301:
There are problems with the example, see the discussion in Remove Setting Method.
(Not fixable in reprints.)
Page 307: “Another reason to be wary of class.forName is that...” should be: “Another reason to be wary of Class.forName is that...” (Class should have a capital C) [Corrected in the 5th printing]
Page 307: “I can use a differenct approach....” should be: “I can use a different approach...” (spelling) [Corrected in the 5th printing]
Page 311: “If the exception us checked, adjust the callers...” should be: “If the exception is checked, adjust the callers...” [Corrected in the 5th printing]
Page 313:
The line of code that says
Assert.isTrue(“amount too large”, amount > _balance);
is in error as the sense of the boolean is the wrong way round. A better line would be
Assert.isTrue(“sufficient funds”, amount <= _balance);[Corrected in the 8th printing]
Page 316:
In the first paragraph of the example, the text “When a client wants a resource, the pool hands it out…” should read “When a client wants a resource, the manager hands it out ...”
Page 324:
In the first code example the line
void createBill(date Date) {
should read
void createBill(Date date) {
Page 324:
In the top code example the line double chargeAmount = charge
(lastBillDate, date) should read double chargeAmount =
chargeFor (lastBillDate, date). (I got the method name
inconsistent with the diagrams.)
[Corrected in the 8th printing]
Page 328: In the motivation paragraph “Pull Down Method” should read “Push Down Method”. (This is what happens when I don't use links for everything!) [Corrected in the 8th printing]
Page 333: “arguments are needed by the labor item, and some are not” should be: “some arguments are needed...” (missing word) [Corrected in the 5th printing]
Page 346: “Whenever we see two similar method” should be: “Whenever we see two similar methods” (plural) [Corrected in the 5th printing]
Page 346:
“The statement method prints statements” should be: “The
statement method prints statements” (font) [Corrected in the 5th printing]
Page 349: The first paragraph should end with a close parenthesis to match the one of the first line. [Corrected in the 15th printing]
Page 351: In the UML Diagram, the relationship between Customer and Statement should be a dependency, not an association.
Page 363: The references to the refactorings on this page are cross referenced with chapter references rather than the usual page references. Worse still, the chapter for Extract Class should be Chapter 7. [Corrected in the 13th printing]
Page 366:
The first reference to figure 12.6 should actually refer to figure 12.5
Errors in the 3rd printing
Page xx: “Joshua suggested the idea of code sketches” should read “Joshua Kerievsky suggested the idea of code sketches” [Corrected in the 5th printing]
Page 2: In the first paragraph “and identifies the type movie” should read “and identifies the type of movie”. [Corrected in the 12th printing]
Page 12:
I've been asked for more information about the double to int rounding. It happens when you have a compound assignment. In other words
int foo=1; foo += 1.5;
compiles, as it is equivalent to
int foo = 1; foo = (int) (foo + 1.5);
I haven't looked into the rationale behind this. (see Java Language Specification, section 15.26.2)
(Not fixable in reprints.)
Page 25: Caption on fig 1.7 “Sequence diagram before extraction...” should be “Sequence diagram after extraction...” [Corrected in the 8th printing]
Page 40: In the code examples on pages 40 and 41 the
references to the field _name should instead be
_title [Corrected in the 12th printing]
Page 76: 3rd para in “Duplicated Code”. “in both classes then Pull Up Field (320)” should read “in both classes then Pull Up Method (322)” [Corrected in the 8th printing]
Page 83: In the Speculative Generality section, first paragraph, second sentence. “Oh, I think we need the ability to this...” should read “Oh, I think we need the ability to do this...”. [Corrected in the 15th printing]
Page 98:
The method testReadAtEnd is incorrect. I looked at my
source files and found the method there to say
public
void testReadAtEnd() throws IOException {
int ch = -1234;
for (int i = 0; i < 141; i++)
ch = _input.read();
assertEquals("read at end", -1, _input.read());
}
Another reason to be glad that these days I'm auto-inserting source code!
[Corrected in the 15th printing]
Page 115: In the third line, “rerun” should be “return” [Corrected in the 15th printing]
Page 119: At the start of the mechanics add a step: “check that the right hand side of the assignment is free of side-effects”. [Corrected in the 24th printing]
Page 120: Last line, “...assigned only to once...” should read “...only assigned to once...” [Corrected in the 15th printing]
Page 120: In the solution statement the phrase “Replace all references to the temp with the expression” should be replaced with “Replace all references to the temp with the new method” [Corrected in the 15th printing]
Page 121: In the last step of the mechanics, I say to use Replace Temp with Query (120), this should be replaced with a reference to Inline Temp (119). Otherwise I'd get a recursive refactoring. The problem continues in the example on page 122 where again the cross reference should be to Inline Temp (119). This was fixed incorrectly in the 8th printing (see below) [Corrected in the 8th printing]
Page 121: This was an incorrect fix to an earlier error. In the last line of the mechanics the refactoring 'Replace Temp with Inline Temp' should read 'Inline Temp'. The same problem occurs on page 122. [Corrected in the 13th printing]
Page 128: In the first paragraph of the motivation the expression “for (int i=0; i<10; i++) needs an extra parenthesis to balance the earlier textual one. [Corrected in the 15th printing]
Page 148:
In the top code example, the line
private double _interestRate
should read
private double _interestRate
as that code is removed at this point.
Page 153: In the second para, third line “As discussed in Lea by section...” should read “As discussed in Lea in section....” [Corrected in the 16th printing]
Page 165: The second to last code sample is incorrect, it should read as follows.
class MfDateSub extends Date {
public MfDateSub nextDay()...
public int dayOfYear()...
[Corrected in the 24th printing]
Page 165: In the final code sample class mfDate
should read class MfDateWrap [Corrected in the 24th printing]
Page 166: In the second to last code sample class
mfDate should read class MfDateWrap [Corrected in the 24th printing]
Page 166:
in the sixth code example, the line
class mfDate {
should read
class MfDateWrap {
Page 166:
In the fifth code example, the line
class MfDate…
should read
class MfDateSub…
Page 167: About a third of the way down, the equals method is incorrect. It should read
public boolean equals(Object arg) {
if (this == arg) return true;
if (! (arg instanceof MfDateWrap)) return false;
MfDateWrap other = ((MfDateWrap) arg);
return (_original.equals(other._original));
}
[Corrected in the 24th printing]
Page 167:
in the fourth code example, the line
class MfDate…
should read
class MfDateWrap…
Page 176: In the second para, (a step in the mechanics) “change the getting method” should read “change the setting method” [Corrected in the 15th printing]
Page 176:
In the method numberOfOrdersFor the line that reads
if (each.getCustomerName().equals(customer)) result++;
should read if (each.getCustomer().equals(customer))
result++; [Corrected in the 8th printing]
Page 177:
In the first state of the method setCustomer the line
that reads _customer = new Customer (customer); should
read _customer = new Customer (arg); [Corrected in the 8th printing]
Page 185: In the second paragraph “biwise xor” shoudl read “bitwise xor” [Corrected in the 12th printing]
Page 193: “to declare that interval window implements Observable” should read “to declare that interval window implements Observer“ [Corrected in the 5th printing]
Page 219: “In a paragraph at around the middle of page, the sentence “...need a new method that returns the code” should read “...need a new method that returns an instance of the new class.” [Corrected in the 8th printing]
Page 222:
At the bottom of the page I make the method getCode
private. I obviously can't do that while any clients of BloodGroup
are using the method. As a result the sentance “I can also privatize
the methods...”, should begin “If no clients use the numeric code I
can also privatize the methods...”
[Corrected in the 16th printing]
Page 222:
“In the crossed out code, the method “public int
getBloodGroup() {” should be “public int
getBloodGroupCode() {” (I had just renamed it!)”
[Corrected in the 8th printing]
Page 225:
The first mention of the create method is missing the
static keyword.
[Corrected in the 13th printing]
Page 241: In the code examples at the bottom of the page, the method isEligibleForDisability should be isNotEligibleForDisability [Corrected in the 4th printing]
Page 258:
In the first code example the line
return Employee.ENGINEER;
should be
return EmployeeType.ENGINEER;
Page 261: In Ron's story, 4th para, “Of course, as soon as you being inspecting...” but should be “Of course, as soon as you begin inspecting...” [Corrected in the 5th printing]
Page 285: The before code contains a rather more serious error than the refactoring is meant to help with as the assertion is always executed. The before code should read:
void setValue (String name, int value) {
if (name.equals(“height”)) {
_height = value;
return;
}
if (name.equals(“width”)) {
_width = value;
return;
}
Assert.shouldNeverReachHere();
}
[Corrected in the 8th printing]
Page 300: In the mechanics section the field should be made final at the end of process not at the begining. [Corrected in the 5th printing]
Page 301:
There are problems with the example, see the discussion in Remove Setting Method.
(Not fixable in reprints.)
Page 307: “Another reason to be wary of class.forName is that...” should be: “Another reason to be wary of Class.forName is that...” (Class should have a capital C) [Corrected in the 5th printing]
Page 307: “I can use a differenct approach....” should be: “I can use a different approach...” (spelling) [Corrected in the 5th printing]
Page 311: “If the exception us checked, adjust the callers...” should be: “If the exception is checked, adjust the callers...” [Corrected in the 5th printing]
Page 313:
The line of code that says
Assert.isTrue(“amount too large”, amount > _balance);
is in error as the sense of the boolean is the wrong way round. A better line would be
Assert.isTrue(“sufficient funds”, amount <= _balance);[Corrected in the 8th printing]
Page 315: The problem statement should read “You are throwing an exception on a condition the caller could have checked first” (the refactoring applies to all exceptions, not just checked ones) [Corrected in the 4th printing]
Page 316:
In the first paragraph of the example, the text “When a client wants a resource, the pool hands it out…” should read “When a client wants a resource, the manager hands it out ...”
Page 324:
In the first code example the line
void createBill(date Date) {
should read
void createBill(Date date) {
Page 324:
In the top code example the line double chargeAmount = charge
(lastBillDate, date) should read double chargeAmount =
chargeFor (lastBillDate, date). (I got the method name
inconsistent with the diagrams.)
[Corrected in the 8th printing]
Page 328: In the motivation paragraph “Pull Down Method” should read “Push Down Method”. (This is what happens when I don't use links for everything!) [Corrected in the 8th printing]
Page 333: “arguments are needed by the labor item, and some are not” should be: “some arguments are needed...” (missing word) [Corrected in the 5th printing]
Page 346: “Whenever we see two similar method” should be: “Whenever we see two similar methods” (plural) [Corrected in the 5th printing]
Page 346:
“The statement method prints statements” should be: “The
statement method prints statements” (font) [Corrected in the 5th printing]
Page 349: The first paragraph should end with a close parenthesis to match the one of the first line. [Corrected in the 15th printing]
Page 351: In the UML Diagram, the relationship between Customer and Statement should be a dependency, not an association.
Page 363: The references to the refactorings on this page are cross referenced with chapter references rather than the usual page references. Worse still, the chapter for Extract Class should be Chapter 7. [Corrected in the 13th printing]
Page 366:
The first reference to figure 12.6 should actually refer to figure 12.5
Errors in the 1st thru 3rd printing
Page xx: “Joshua suggested the idea of code sketches” should read “Joshua Kerievsky suggested the idea of code sketches” [Corrected in the 5th printing]
Page 2: In the first paragraph “and identifies the type movie” should read “and identifies the type of movie”. [Corrected in the 12th printing]
Page 12:
I've been asked for more information about the double to int rounding. It happens when you have a compound assignment. In other words
int foo=1; foo += 1.5;
compiles, as it is equivalent to
int foo = 1; foo = (int) (foo + 1.5);
I haven't looked into the rationale behind this. (see Java Language Specification, section 15.26.2)
(Not fixable in reprints.)
Page 25: Caption on fig 1.7 “Sequence diagram before extraction...” should be “Sequence diagram after extraction...” [Corrected in the 8th printing]
Page 37: “Class rental” should be “class Rental” (capitalization) and “class movie” should be “class Movie” (capitalization) [Corrected in the 3rd printing]
Page 40: In the code examples on pages 40 and 41 the
references to the field _name should instead be
_title [Corrected in the 12th printing]
Page 48: The second line: “class Rental...” should be: “class Movie...” [Corrected in the 3rd printing]
Page 70: Steve McConnell's last name is misspelled in two places. [Corrected in the 3rd printing]
Page 76: 3rd para in “Duplicated Code”. “in both classes then Pull Up Field (320)” should read “in both classes then Pull Up Method (322)” [Corrected in the 8th printing]
Page 82: The sentence “If you add a new clause to the switch, you have to find all these switch, statements and change them.” The second comma should be removed. [Corrected in the 3rd printing]
Page 83: In the Speculative Generality section, first paragraph, second sentence. “Oh, I think we need the ability to this...” should read “Oh, I think we need the ability to do this...”. [Corrected in the 15th printing]
Page 85: “Replace Delegation with Inheritance (355)” in Inappropriate Intimacy should be “Replace Inheritance with Delegation (352)” [Corrected in the 3rd printing]
Page 92: On Figure 4.1 the line from TestSuite to Test should be an association not a generalization (see diagram below). Also the package name should be junit.framework. [Corrected in the 3rd printing]
Page 92: In the test file for the example, George Headley's career total was actually 2190 test riuns. [Corrected in the 3rd printing]
Page 98:
The method testReadAtEnd is incorrect. I looked at my
source files and found the method there to say
public
void testReadAtEnd() throws IOException {
int ch = -1234;
for (int i = 0; i < 141; i++)
ch = _input.read();
assertEquals("read at end", -1, _input.read());
}
Another reason to be glad that these days I'm auto-inserting source code!
[Corrected in the 15th printing]
Page 115: In the second sentence, “oustanding” should be “outstanding” [Corrected in the 3rd printing]
Page 115: In the third line, “rerun” should be “return” [Corrected in the 15th printing]
Page 119: At the start of the mechanics add a step: “check that the right hand side of the assignment is free of side-effects”. [Corrected in the 24th printing]
Page 120: Last line, “...assigned only to once...” should read “...only assigned to once...” [Corrected in the 15th printing]
Page 120: In the solution statement the phrase “Replace all references to the temp with the expression” should be replaced with “Replace all references to the temp with the new method” [Corrected in the 15th printing]
Page 121: In the last step of the mechanics, I say to use Replace Temp with Query (120), this should be replaced with a reference to Inline Temp (119). Otherwise I'd get a recursive refactoring. The problem continues in the example on page 122 where again the cross reference should be to Inline Temp (119). This was fixed incorrectly in the 8th printing (see below) [Corrected in the 8th printing]
Page 121: This was an incorrect fix to an earlier error. In the last line of the mechanics the refactoring 'Replace Temp with Inline Temp' should read 'Inline Temp'. The same problem occurs on page 122. [Corrected in the 13th printing]
Page 128: In the first paragraph of the motivation the expression “for (int i=0; i<10; i++) needs an extra parenthesis to balance the earlier textual one. [Corrected in the 15th printing]
Page 148:
In the top code example, the line
private double _interestRate
should read
private double _interestRate
as that code is removed at this point.
Page 153: In the second para, third line “As discussed in Lea by section...” should read “As discussed in Lea in section....” [Corrected in the 16th printing]
Page 165: The second to last code sample is incorrect, it should read as follows.
class MfDateSub extends Date {
public MfDateSub nextDay()...
public int dayOfYear()...
[Corrected in the 24th printing]
Page 165: In the final code sample class mfDate
should read class MfDateWrap [Corrected in the 24th printing]
Page 166: In the second to last code sample class
mfDate should read class MfDateWrap [Corrected in the 24th printing]
Page 166:
in the sixth code example, the line
class mfDate {
should read
class MfDateWrap {
Page 166:
In the fifth code example, the line
class MfDate…
should read
class MfDateSub…
Page 167: About a third of the way down, the equals method is incorrect. It should read
public boolean equals(Object arg) {
if (this == arg) return true;
if (! (arg instanceof MfDateWrap)) return false;
MfDateWrap other = ((MfDateWrap) arg);
return (_original.equals(other._original));
}
[Corrected in the 24th printing]
Page 167:
in the fourth code example, the line
class MfDate…
should read
class MfDateWrap…
Page 176: In the second para, (a step in the mechanics) “change the getting method” should read “change the setting method” [Corrected in the 15th printing]
Page 176:
In the method numberOfOrdersFor the line that reads
if (each.getCustomerName().equals(customer)) result++;
should read if (each.getCustomer().equals(customer))
result++; [Corrected in the 8th printing]
Page 177:
In the first state of the method setCustomer the line
that reads _customer = new Customer (customer); should
read _customer = new Customer (arg); [Corrected in the 8th printing]
Page 185: In the second paragraph “biwise xor” shoudl read “bitwise xor” [Corrected in the 12th printing]
Page 193: “to declare that interval window implements Observable” should read “to declare that interval window implements Observer“ [Corrected in the 5th printing]
Page 219: “In a paragraph at around the middle of page, the sentence “...need a new method that returns the code” should read “...need a new method that returns an instance of the new class.” [Corrected in the 8th printing]
Page 222:
At the bottom of the page I make the method getCode
private. I obviously can't do that while any clients of BloodGroup
are using the method. As a result the sentance “I can also privatize
the methods...”, should begin “If no clients use the numeric code I
can also privatize the methods...”
[Corrected in the 16th printing]
Page 222:
“In the crossed out code, the method “public int
getBloodGroup() {” should be “public int
getBloodGroupCode() {” (I had just renamed it!)”
[Corrected in the 8th printing]
Page 225:
The first mention of the create method is missing the
static keyword.
[Corrected in the 13th printing]
Page 241: In the code examples at the bottom of the page, the method isEligibleForDisability should be isNotEligibleForDisability [Corrected in the 4th printing]
Page 258:
In the first code example the line
return Employee.ENGINEER;
should be
return EmployeeType.ENGINEER;
Page 261: In Ron's story, 4th para, “Of course, as soon as you being inspecting...” but should be “Of course, as soon as you begin inspecting...” [Corrected in the 5th printing]
Page 285: The before code contains a rather more serious error than the refactoring is meant to help with as the assertion is always executed. The before code should read:
void setValue (String name, int value) {
if (name.equals(“height”)) {
_height = value;
return;
}
if (name.equals(“width”)) {
_width = value;
return;
}
Assert.shouldNeverReachHere();
}
[Corrected in the 8th printing]
Page 300: In the mechanics section the field should be made final at the end of process not at the begining. [Corrected in the 5th printing]
Page 301:
There are problems with the example, see the discussion in Remove Setting Method.
(Not fixable in reprints.)
Page 307: “Another reason to be wary of class.forName is that...” should be: “Another reason to be wary of Class.forName is that...” (Class should have a capital C) [Corrected in the 5th printing]
Page 307: “I can use a differenct approach....” should be: “I can use a different approach...” (spelling) [Corrected in the 5th printing]
Page 311: “If the exception us checked, adjust the callers...” should be: “If the exception is checked, adjust the callers...” [Corrected in the 5th printing]
Page 313:
The line of code that says
Assert.isTrue(“amount too large”, amount > _balance);
is in error as the sense of the boolean is the wrong way round. A better line would be
Assert.isTrue(“sufficient funds”, amount <= _balance);[Corrected in the 8th printing]
Page 315: The problem statement should read “You are throwing an exception on a condition the caller could have checked first” (the refactoring applies to all exceptions, not just checked ones) [Corrected in the 4th printing]
Page 316:
In the first paragraph of the example, the text “When a client wants a resource, the pool hands it out…” should read “When a client wants a resource, the manager hands it out ...”
Page 324:
In the first code example the line
void createBill(date Date) {
should read
void createBill(Date date) {
Page 324:
In the top code example the line double chargeAmount = charge
(lastBillDate, date) should read double chargeAmount =
chargeFor (lastBillDate, date). (I got the method name
inconsistent with the diagrams.)
[Corrected in the 8th printing]
Page 328: In the motivation paragraph “Pull Down Method” should read “Push Down Method”. (This is what happens when I don't use links for everything!) [Corrected in the 8th printing]
Page 333: “arguments are needed by the labor item, and some are not” should be: “some arguments are needed...” (missing word) [Corrected in the 5th printing]
Page 346: “Whenever we see two similar method” should be: “Whenever we see two similar methods” (plural) [Corrected in the 5th printing]
Page 346:
“The statement method prints statements” should be: “The
statement method prints statements” (font) [Corrected in the 5th printing]
Page 349: The first paragraph should end with a close parenthesis to match the one of the first line. [Corrected in the 15th printing]
Page 351: In the UML Diagram, the relationship between Customer and Statement should be a dependency, not an association.
Page 355: first line of section “Motivation”, “...Replace Delegation with Inheritance (355)” should read “Replace Inheritance with Delegation (352)” [Corrected in the 3rd printing]
Page 363: The references to the refactorings on this page are cross referenced with chapter references rather than the usual page references. Worse still, the chapter for Extract Class should be Chapter 7. [Corrected in the 13th printing]
Page 366:
The first reference to figure 12.6 should actually refer to figure 12.5
Page 390: “...vivc.edu” should be “uiuc.edu” [Corrected in the 3rd printing]
Page 405: Last box on bottom right should have “Hello World” (not “out”) [Corrected in the 3rd printing]
Page 405: Parse tree for program should have “hello” (method name) in lower-case. [Corrected in the 3rd printing]
Page 414: Reference to JUnit in the URL “compuserv” should be “compuserve” [Corrected in the 3rd printing]
Corrected version of fig 4.1 on page 92.
Many thanks to Mike Anderson, Alex Aptekman, Beth Egan Bradtke, Greg Cohoon, George Cowan, Bruce Crawford, John Dale, Nick Dallet, Dion Dock, Jutta Eckstein, Raimar Falke, Paul Haahr, Akira Hirasawa, John Hollister, Heinz Kabutz, Bernd Kahlbrandt, Adam Kiezun, Bart Koestner, Jung-joon Kim, Mark Kinzie, Hamish Lawson, Hwijae Lee, Jaeik Lee, Marc Lepage, Ron Lusk, Chuck McKinnon, Rory Molinari, Anthon van der Neut, Jonas Nyrup, Orjan Petersson, Jon Reid, Oliver Rode, Gavin Scott, Patricia Shanahan, Pradyumn Sharma, Joel Smith, Ellen Spertus, Dawie Strauss, Frank Tip, Madhavi Tolety, and Bill Wake, Hirohide Yazaki for spotting and telling me about these errors