Is this an education problem?

Object-Oriented Programmers
Reject Object-Oriented Programming

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!

OOP advantages revisited

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:

  1. OOP supports data-representation standards

    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.

  2. OOP supports generic-specific hierarchy

    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 Person class, 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.

  3. OOP localizes bad-data errors

    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