Massive Mistreatment of Non-Objects

Paul & Harvey Deitel: Java: How to Program, Tenth Edition,
2015, Pearson, ISBN 0-13-257565-5, 1186 pages.
Reviewed by Conrad Weisert, May 14, 2014

About all you have to know about this book is apparent from this nearly-100-line example on pages 740-742:

 // Employee class
  public class Employee
   private String firstName;
   private String lastName;
   private double salary;
   private String department;

   //  Constructor
   public Employee(String firstName, String lastName,
     double salery, String department)
     this.firstName = firstName;
     this.lastName = lastName;
     this.salary = salary;
     this.department = department;

  // set firstName
  public void setFirstName(String firstName)
    this firstName = firstName;

  //  get firstName
  public String getFirstName()
    return firstName;

  // set lastName
  public void setlastName(String lastName)
    this lastName = lastName;

  //  get lastName
  public String getLastName()
    return lastName;
 // set salary
 public void setSalary(double salary) 
    this.salary = salary;

 // get salary
 public double getSalary() 
   return salary;

 // set department 
 public void setDepartment(String department)
   this.department = department;
 // get department
 public String getDepartment()
   return department;

 //  return Employee's first and last name combined
 public String getName()
   return String.format("%s, %s", getFirstName(), getLastName());

 //  return a String containing the Employee's information
 public String toString()
  return String.format("%-8s %-8s %8.2f %s",
    getFirstName(), getLastName(), getSalary(), getDepartment()); 
 }  //  end method toString
} //  end class Employee

After more than 700 pages of background explanations, does all that painfully repetitive code support the object-oriented prosgramming paradigm? Would that example earn a passing grade for a student in an introductory OOP course? Let's see.


Four member data items are declared at the start of the class definition. All four of them are seriously misguided and need major change!

Employee's Name

Experienced programmers may argue over whether a pair of unrestricted character strings constitutes a suitable way of representing names of people who work for the organization, and we'll skip taking a position here. What is not controversial, however, is that the choice doesn't belong to an Employee class.

The organization may, in the same application or in others, also need to represent names of customers, names of members, names of contributors, names of students, names of authors, or names of subscribers. Should programmers involved in designing support applications be free to choose how those names will be represented in programs and databases? What if some of them are in foreign cultures that have different traditions for naming people?

Clearly, the organization needs a standard for representing names of people, and with object-oriented technology that standard should be implemented by a PersonName class. Our Employee class needs to replace the first two String members by a single PersonName member.


The authors warned us in an earlier chapter (pp. 337-338) not to use floating point for monetary calculations, and then went ahead and did so in subsequent examples. Unfortunately, their proposed alternative wasn't much better, but in an object-oriented world, that issue shouldn't be resolved in an Employee class. The need for a robust type-safe Money class is obvious.


Again, an unrestricted character string invites errors and thwarts future changes. Unless the organization anticipates an infinite number of departments and is willing to tolerate spelling mistakes, an enum (or equivalent editing restriction) is clearly called for here.

Member summary

So far, then, experienced OOP practitioners can agree on this vital revision to the beginning of Deitel & Deitel's example:

   public class Employee  {
   	PersonName name;
        Money      salary;
        DeptID     department;
But wait! There's more!

Missing data

The most essential piece of data about an Employee is the identifier used for tax purposes, in the United States the SocialSecurity number. And just to comply with tax withholding laws, we also need dateOfBirth and noOfDependents. Other important dates including dateHired are also missing, perhaps because this huge introductory programming book never satisfactorily explains how to do basic date calculations and manipulations.1

An almost identical Person class pops up again 300 pages later (in a chapter about JDBC), this time including member data for phoneNumber and Email, which surely ought to be pertinent to an Employee. No mention is made of the relationship between Employee and Person, an obvious opportunity either to embrace or to reject inheritance.

Taming verbosity

I once had to oversee a contract in which the contractor was to be paid according to (among other measures) the number of lines of code produced. The contract didn't specify whether blank lines and comment lines were to be counted, and so the vendor padded his source code with lots of white space and redundant comments. We were expected, in effect, to pay for programming by the pound.

It's obvious to anyone that a comment // get first name immediately preceding a function header public String getFirstName() is pointless padding. Since Deitel & Deitel's book weighs over three pounds, they hardly needed to pad it. Indeed, with the original data definitions the whole set of get accessors could have been reduced from a half-page of code to these much more readable lines:

 //  Accessors
  public String getFirstName()  {return firstName; }
  public String getLastName()   {return lastName;  }
  public double getSalary()     {return salary;    }
  public String getDepartment() {return department;} 

We won't discuss all those set accessors that undermine object integrity. They are unnecessary and naïvely ill-advised.

The index contains separate lines for Color.BLACK, Color.BLUE, Color.CYAN, Color.DARK_GRAY, Color.GRAY, Color.GREEN, Color.LIGHT_GRAY, Color.MAGENTA, Color.ORANGE, Color.PINK, Color.RED, Color.WHITE, Color.YELLOW.   Each of them refers to page 192. (But I was looking for the Color.PURPLE.)

Positive features

Fourteen years ago I ended a review of another disappointing book by observing sadly that "One can be an authority on a programming language without knowing much about programming." That certainly applies here, too. The Deitels have been working with Java for many years, and they're well acquainted with Java's features and rules. But they don't seem to grasp the object paradigm or other principles of effective high-quality modular program structure.

Nevertheless, there's solid information here for the critical reader. The explanations are lucid. Diagrams are helpful. The examples, although often seriously misguided, serve to illustrate how Java works.

The text is liberally sprinkled with short "tips", "observations", and "good programming practices". Many of them are useful, but they lack structure.

Alternative version

The above discussion refers to the "Late Objects Version". The authors and the publisher have also brought us an "Early Objects Version" (ISBN 0-13-380780-0). It introduces classes and objects in chapter 3 and returns for a "deeper look" in chapter 8. The Employee example is expanded somewhat to serve as an abstract superclass for various categories of employee (CommissionEmployee), but it shares most of the flaws of the above version.

Either of these books might be a useful second or third Java text in the library of an experienced professional, but for a beginner learning the object paradigm or for a serious course textbook they are definitely not recommended.

1—That omission is presumably taken care of by the advice on page 313: "You can learn more about the Date/Time API's classes at: . . . "

Last modified May 26, 2014

Return to book reviews.
Return to IDI home page.