by Conrad Weisert
December 9, 2005
© 2005 Information Disciplines, Inc.
This article may be circulated freely as long as the copyright notice is included.
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:
Moneyclass2 that captured none of the behavior exhibited by currency objects in business applications, but simply served as a helper for another class,
money_put, that provided control over external format roughly comparable to what PL/I's
PICTUREattribute had supported three decades earlier.
The literature, especially in periodicals, over the past half-dozen years is full of longer examples.
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:
|We need a ||Any reasonable
|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.
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:
Return to table of contents
Last modified February, 2006