When the object paradigm is available, use it!

Missed O.O. Opportunities Are Serious Errors

by Conrad Weisert
July 1, 2013
© 2013 Information Disciplines, Inc.


We've complained about a surprisingly common shortcoming of many programs coded in an object-oriented programming language:   ignoring or bypassing the object paradigm!

Three years ago we noted a tendency to use raw string data for nearly every elementary item having a text representation. Later we observed a puzzling tendency to fall back upon primitive built-in types instead of defining object-oriented classes for numeric data.

Since then we've encountered a steady stream of further examples of these practices, not only in students' exercises and clients' application systems, but also in advanced textbooks on object-oriented programming. We haven't kept counts, but this may well be the most common serious mistake both by rank & file programmers and by presumed "experts" in preparing object-oriented programs.

The rules

Here's what we advise our students and colleagues who will be using an object-oriented tool:

  1. Whenever a numeric type has a unit of measure, it should be a class1. Thus we expect to find appropriate class definitions if the program manipulates: as well as quantities derived from the above, such as Area and Velocity.

  2. Whenever a text (character string) type has a specific format2, it should be a class. Thus we expect to find appropriate class definitions if the program manipulates: as well as names of practically any composite data item, such as PersonName, CompanyName, and CityName.
unless there's a persuasive reason3 to do otherwise.

Isn't string data already object-oriented?

In C++, Java, and C# a standard library string class relies, more or less, on the language's facilities for defining and using an object-oriented class. A naïve programmer might conclude, therefore, that defining text data items as instances of string makes the processing of those data items object-oriented.

Wrong!   The standard string classes exist to compensate for the omission of a built-in character-string type in C, the ancestor of those three object-oriented languages. It turns out that the class definition and object manipulation facilities in those languages are well suited to character-string handling, so there was no need to support built-in string data as found in PL/I, Basic, and Cobol.

But that doesn't automatically make all text data items bona fide application-domain objects. See Too Many String Data Items from three years ago for further explanation.

Does an elementary item class impose a performance penalty?

Well, in Java it does, and in C++ or C# it shouldn't. Java's designers stubbornly resisted the pressure to support so-called "value objects" and made instances of every defined class "reference objects". Java programs get loaded with expensive heap allocation and freeing and with redundant boxing and unboxing, not to mention awkward circumventing of the lack of expression syntax for objects. My advice:

  1. Avoid Java for computation-intensive programming.
  2. If you must use Java for such programs, use objects, anyway, unless the performance turns out to be intolerable. The reliability and maintainability of object-oriented computation can easily offset some degree of sluggish executions.

In 2013 no one should be writing Fortran programs in Java or any other object-oriented language.

My book addresses this topic in depth.

More to come

Later this summer we'll examine some possible conflicts between advice given by some experts (Bill Wagner) and advice from other experts (Bjarne Stroustrup) and others.

1—Actually C# calls it a struct, but it's still conceptually an object-oriented class.
2—even just a fixed or maximum length
3—We rarely if ever encounter such a justification, but we're reluctant to say "never" or "always".

Return to Technical articles
IDI Home page

Last modified July 9, 2013