The canonical object idiom

Defining a baseline set of functionality for objects

1 2 Page 2
Page 2 of 2

Note that defining finalize() is not part of this idiom. A finalizer is not appropriate in general cases, although under certain circumstances you may want to write a finalizer. For advice on writing finalizers, follow the link from the Resources section to a previous Design Techniques article on that subject.

Note also that defining toString() is missing from the list above. I left it out because I believe Object has a reasonable default implementation for this method. Object's toString() method returns a string composed of the name of the class, an "at" sign ("@"), and the unsigned hexadecimal representation of the hash code of the object. If you do override toString, you should return a string that "textually represents" the object. The returned result should be concise, informative, and easy to read.

One other thing missing from the canonical object idiom is a no-arg constructor. Any class that has a no-arg constructor and implements Serializable is a JavaBean. See the Resources section for a link to a discussion of when it is appropriate to make a class into a bean.

Idiom issues

To help spark some discussion on the Flexible Java Forum, a discussion forum devoted to Java design topics, I will throw out some of the issues that may present themselves with this idiom (see the Resources section for a link to the forum):

  • Is "canonical object" the best name?

  • Am I justified in excluding a requirement to override toString from my canonical object recipe?

  • Should I throw something besides InternalError from the catch clause that catches CloneNotSupportedException? My general advice (given in my "Designing with Exceptions" article) is that programs should throw only exceptions, never errors. Usually the VM throws the errors. But in this case, I have implemented Cloneable. Thus, if Object's clone() implementation throws CloneNotSupported, I think that may qualify as an internal error to me. Since this "internal error" will likely never happen, what I throw probably isunimportant. But I'd still feel better about throwing an exception rather than an error. Perhaps what we need is a java.lang.ThisWasntSupposedToEverHappenException.

  • I'm a bit concerned about promoting the catching of CloneNotSupportedException at all, because, as I described above, it does tie the hands of anyone wishing to disallow cloning in a subclass.

  • Of course, there is that nagging question of the no-arg constructor, which, if it is part of the canonical object idiom, would make every canonical object into a JavaBean. This question has its own forum topic; you can find a link to it in the Resources section.

Next month

In next month's Design Techniques I'll talk about composition, inheritance, and interfaces.

A request for reader participation

I encourage your comments, criticisms, suggestions, flames -- all kinds of feedback -- about the material presented in this column. If you disagree with something, or have something to add, please let me know.

You can either participate in a discussion forum devoted to this material, enter a comment via the form at the bottom of the article, or e-mail me directly using the link provided in my bio below.

Bill Venners has been writing software professionally for 12 years. Based in Silicon Valley, he provides software consulting and training services under the name Artima Software Company. Over the years he has developed software for the consumer electronics, education, semiconductor, and life insurance industries. He has programmed in many languages on many platforms: assembly language on various microprocessors, C on Unix, C++ on Windows, Java on the Web. He is author of the book: Inside the Java Virtual Machine, published by McGraw-Hill.

Learn more about this topic

  • Bill Venners' next book is Flexible Java
  • Bill Venners is currently riding his bike through various European countries. As he encounters Internet cafes, he'll be posting reports about his trip. Follow along at
  • The discussion forum devoted to the material presented in this article
  • Links to all previous design techniques articles
  • Recommended books on Java design, including information by the Gamma, et al., Design Patterns book
  • A transcript of an e-mail debate between Bill Venners, Mark Johnson (JavaWorld's JavaBeans columnist) and Mark Balbe on whether or not all objects should be made into beans
  • Source packet that contains the example code used in this article
  • Object orientation FAQ
  • 7237 Links on Object Orientation
  • The Object-Oriented Page
  • Collection of information on OO approach
  • Design Patterns Home Page
  • A Comparison of OOA and OOD Methods
  • Object-Oriented Analysis and Design MethodsA Comparative Review
  • Patterns discussion FAQ
  • Patterns in Java AWT
  • Software Technology's Design Patterns Page
  • Previous Design Techniques articles
1 2 Page 2
Page 2 of 2