by Conrad Weisert
© 2012 Information Disciplines, Inc., Chicago
NOTE: This article may be circulated freely as long as the copyright notice is included.
"One can be an authority on a programming language|
without knowing much about programming."
A dozen years ago I ended a review of an incompetent book with that observation. Regrettably since then we keep encountering opportunities to apply it to other books, articles, and modern software.
Recently I've been encountering more and more examples of a somewhat more specific and highly disappointing variation:
One can be an authority on an object-oriented programming language|
while rejecting1 much of the object-oriented paradigm!
The object paradigm has been around for decades. It has become established as the mainstream technology for much application software development because it offers a number of significant advantages over old-fashioned pure procedural programming. Here are some of those advantages along with surprising and frustrating resistance from some programmers who use an object-oriented programming language every day:
Constructor functions convert data from one or more external forms to standard, simple, and predictable internal member data items.
Some programmers, nevertheless, impose awkward external representations upon their objects, even in extreme cases multiple representations as member data! Programmers using Java often forgo objects altogether for their elementary data items.
Often called is-a relationships, the idea is to "factor out" what is common to all instances of some broad type as a highly reusable base class and then derive specialized versions for application-specific needs. This is a variation on traditional "bottom-up" development of general utility modules.
When I recently invited ideas for a common
however, several presumably experienced programmers responded by declaring the
very notion impossible and nonsensical. "You can't possibly design, much less
develop, such a class," they asserted, "without
knowing what application(s) it will be used by." For them general-purpose
reusable classes are limited to containers and GUI structures.
Once an object has been created, programs needn't check it for validity. If the source of the data is external, the constructors or a few other methods will validate it in the process of converting it to its valid internal form.
Surprisingly, some programmers still insist upon checking objects for valid values. Even more surprisingly, some organizations or large development projects impose standards requiring this wasteful practice!
Instead of helping to simplify programs an object-oriented programming language has made some programs even more complicated, more repetitious, harder to change, and much harder to understand and debug.
1—Deliberate "rejecting" may not apply to all such programmers. Some of them may just be ignorant of or indifferent to OOP concepts.
Return to IDI home page
Last modified July 1, 2012