Misguided distortion of OOP becoming commonplace

Trade Journals Promote Pseudo Objects

by Conrad Weisert
December 9, 2005
© 2005 Information Disciplines, Inc.

This article may be circulated freely as long as the copyright notice is included.


Background

In the mid 1990s object-orientation moved from being an experimental novelty to the mainstream of programming. Today programmers take for granted that OOP is a central element of their software development methodology. For the most part, that has been a good thing. OOP encourages and enforces a level of modularity that potentially contributes to program maintainability and component reuse.

But not long afterwards we began to see rather extreme, sometimes bizarre examples of what objects are about. Instead of modeling entities in the application domain, many (in Java often most) object-oriented classes defined internal program structures that had nothing to do with any data the users would be aware of. Other object-oriented classes didn't even do that, but merely served as packaging artifices for various independent functions. We've called the latter pseudo classes. Rather than simplifying program structure, many of these classes imposed layers of complexity that added to the cost and unpredictability of software maintenance, and led some managers to conclude that OOP is overrated if not harmful.

Short examples promoting such odd practices that appeared in respectable publications included:

The literature, especially in periodicals, over the past half-dozen years is full of longer examples.

A new entry

Dr. Dobb's Journal may not be a scholarly publication, but it's read by practicing programmers, especially by impressionable beginners. Misguided advice in its pages can exert lingering and contagious influence for years.

An article in the December issue (p. 30) describes an object-oriented solution to a "problem" encountered by the author. Here's a summary of the author's proposals with my comments:
Proposed need/strategy Comments
We need a month data type, so that we can sort dates by month irrespective of year, e.g. for a birthday reminder list. Any reasonable Date class provides an accessor function for the month, and you can easily pass to your sort routine a comparison operator function that uses it.
The member data in the month class can be a character representation of any of the legitimate English full names or abbreviations, including lower- and upper-case versions. Private member data constitute the internal representation of an object. If we really need a pure month class, there's no reason to choose any hidden internal representation other than the simplest, in this case obviously an integer 1 - 12. (The English character strings are appropriate as external representations to be displayed on a report or entered as input data.)
Let's specify a even more clever encoding that packs into a binary integer the case and length of the character string name or abbreviation along with the month number. Wow!
An auxiliary MonthOrder pseudo class packages the set of 24 possible character-string values, as a hash table. A hash table is for optimizing look-up on the input side. The article is unclear about the expected sources of such input. The author implies that the input month names will be embedded in free text and discusses the result of comparing a month name with arbitrary text! (In a GUI data-entry program, you'd simply use a list of month names, and store the corresponding month number.) But if the problem was to extract month information from free-text documents, that's not the problem the proposed classes solve.

Those proposed classes hopelessly confuse the notion of object with the notion of data representation and, at best, serve to make a simple problem awfully complicated.

If a program wants to display month names, full or abbreviated, on a screen or on a report it needs only a simple table, not a messy special object. The CalendarInfo class on this web site packages those tables in a simple, straightforward, and time-tested manner.

A check list for O.O. classes

I'm not proposing here exhaustive guidelines for object-oriented design, but let me suggest a few pointers to help avoid the pseudo objects problem:

  1. Every object should represent either: Be very suspiscious of any other objects, especially those that implement messy, complicated, procedural techniques.

  2. An object's private data members constitute it's internal data representation, the unique, simplest, and most flexible way of representing the object's value. Never try to support multiple alternative representations of the same value, and be suspicious of character string representations of numeric or discrete data.

  3. Prefer using existing high-quality classes to inventing new ones.

  4. Prefer broad-scope abstractions to narrow problem-specifics.

1 -- March, April, and May, 1998, issues.
2 -- This web site provides freeware C++ and Java Money classes that support the behavior of currency objects.
3 -- My rebuttal article appeared in ACM SIGPLAN Notices, April, 2002

Return to table of contents
technical articles

Last modified February, 2006