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.

corrected figure 4.1


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