Can we have too many objects with OOP?

Why Are We Instantiating Non-Objects?

Conrad Weisert, August 1, 2011

Background—Purposes and distortions of OOP

Whether you're a strong supporter of the object paradign or an OOP-doubter, you probably agree that the original excitement surrounding objects was driven by a desire to simplify software development and maintenance. OOP was bringing us an elegant way of enforcing modularity.

Before long, however, we started seeing examples in which the use of objects produced programs that were longer and more complicated than the equivalent procedural module. An extreme example appeared in, of all places, the Communications of the ACM, October, 2001, under the title "Hello World Considered Harmful".

The author chided fellow instructors in elementary Computer Science for failing to exploit modern object technology in the classic first executable program. He showed an alternative in which:

Amazingly, he maintained that the example, which you can see in the original or in my ACM SIGPLAN Notices comment the following April, not only is object oriented but also a suitable vehicle for teaching objects to beginners!

We still encounter a few professional programmers and even well-known "experts" who seem to believe that the more "objects" a program creates the more object-oriented the program is, even objects that represent no entity and exhibit no behavior.

Java problem

Although confusion over the object paradigm is felt among some programmers using Smalltalk®, C++, C#, and other object-oriented programming languages, it is by far most prevalent among Java programmers. It's easy to see why.

Java uses classes not only as templates for creating objects, but also as packaging artifices for independent functions that, in the other languages, aren't required to have any such relationship. In Java, therefore, there is always some class that the program can instantiate by invoking new.

Several years ago we offered a check list for creating objects. Since then the issue has grown to the point where I would offer an actual rule for Java programmers:

Weisert's Rule1 for instantiating Java objects

  1. The target of new should be a noun.
  2. That noun should represent something real, either:
    1. a data item in the application domain, or
    2. a programming artifact, such as a collection, a form, or a connection to a file or a remote site.
  3. In either case the created object should:
    1. have a state or value (private member data items), and
    2. exhibit behavior in response to accessible methods.

If there's a good reason to depart from the above, it must be explained in commentary. What does this object represent? Why is it needed?

The rule applies also, of course, to other O.O. programming languages, but they don't seem to be having quite the struggle that the Java community has been undergoing.

Red flags

If we're reading Java source code and we come upon one of these:

without a clear explanation, we can be sure that something is terribly wrong. Most likely, the programmer has mastered details of the Java language without understanding the underlying concepts of the object paradigm.
1—Naming a rule after oneself is more an inside joke for students and colleagues. Surely others have offered virtually the identical rule, and they're welcome to call it whatever they propose. (But surprisingly, many books on Java programming take no notice).

Last modified 4 August 2011

Return to technical articles .
Return to IDI home page.