If OOP is so great, why don't its promoters use it?

Another "Object-Oriented" book
rejects the object paradigm!

©Conrad Weisert, October 12, 2017

Stephen R. Schach: Object-Oriented Software Engineering, 2008,
McGraw-Hill Higher Education, ISBN 978-0-07-352333-0.

The following example (somewhat tidied up here) appears on page 540 of this 558-page volume:

 //  Mortgage class

 public class Mortgage {
  String mortgageeName;
  float  price;
  String dateMortgageIssued;
  float  weeklyIncome;
  float  annualPropertyTax;
  float  annualInsurancePremium;
  float  mortgageBalance;
  static final float  INTEREST_RATE;
  static final int    NO_OF_PAYMENTS;
  static final float  WEEKS_IN_YEAR;
    .  (3-dozen methods, presumably public,
    .    mostly read- and write-accessors)

So, what's wrong with that? Just about everything! Here are a few obvious issues:

  1. Five variables representing amounts of money are declared as primitive floating-point numbers. But Java's float type doesn't provide the accuracy that financial calculations require. Clearly an object-oriented Money class1 is needed.

  2. Representing a date as a raw string is silly and error-prone. The Java library provides a Date class, and if we don't like it (we don't; see footnote)1 we can develop our own.

  3. Specifying terms (INTEREST_RATE and NO_OF_PAYMENTS) as class data implies that they're the same for every mortgage in the user institution. That's highly unlikely.

  4. It's also highly unlikely that the number of weeks in a year would be different for mortgages than for other calendar calculations. Either that constant is misplaced in the Mortgage class or it needs explanation.

  5. (not shown above) There are read accessors and ill-advised write accessors for each of the seven member data items, a mark of amateurish design and a threat to data integrity and future flexibility.

  6. The format of the mortagee's name is unspecified, and it's unclear whether both individuals and organizations are supported. A Customer class with subclasses IndividualCustomer and OrganizationCustomer are probably needed. Those classes would specify contact information, credit rating, etc., and all we need here is a key to a record in a Customer master file.

It seems odd that a book with "object-oriented" in its title would present a major example that doesn't use objects at all. At the very least a competent class designer would begin with something more like this:

 //  Mortgage class

 public class Mortgage {
  CustomerID custno;   	
  Money      price;		
  Date       dateIssued;
  Money      weeklyIncome;
  Money      annualTax;
  Money      annualInsurancePremium;
  Money      balance;	       

So, having corrected some of what's wrong with this example, we may note what's missing. Where does this Mortgage structure identify the property being mortgaged? If it should become necessary to foreclose and seize the property or re-assess it after alterations, how would the bank know where to find it? The book shows several other related data structures, but there's no obvious link to this mortgage data.

And what if the customer has more than one mortgage with this institution on different properties? Which one does a given instance of this data structure pertain to?

Finally, we note a few mysterious members. Exactly what will be the result or the purpose of invoking these?

Those samples desperately need explanatory commentary, both in these design documents and in the actual source code.

This thick book contains some helpful guidance, but too much bad advice, too much misguided advocacy of UML, and far too many missed opportunities to exploit OOP.


1—This web site contains freeware Java Money and Date class definitions.

Last modified October 29, 2017

Return to book reviews
technical articles.
IDI home page.