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.
Here's what we advise our students and colleagues who will be using an object-oriented tool:
stringdata already object-oriented?
In C++, Java, and C# a standard library
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
the processing of those data items object-oriented.
Wrong! The standard
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,
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.
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:
In 2013 no one should be writing Fortran programs in Java or any other object-oriented language.
My book addresses this topic in depth.
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.
struct, but it's still conceptually an object-oriented class.
Return to Technical articles
IDI Home page
Last modified July 9, 2013