Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

The canonical object idiom

Defining a baseline set of functionality for objects

By Bill Venners, JavaWorld.com, 10/01/98

Page 2 of 5

The value of the canonical object idiom

The canonical object idiom can be useful to you in several ways. First, this idiom can guide you when you are deciding whether to support cloning or serialization in a particular class, and which java.lang.Object methods, if any, you should override in that class. You can use this idiom as a starting point with each class you define, and depart from the idiom only if you feel special circumstances justify such a departure. In addition, knowledge of this idiom should make your fellow programmers feel a vague sense of guilt in their attempts to avoid thinking about these issues when they design a class! And, hopefully, this guilt will encourage your coworkers to design objects that support the baseline object services defined by the canonical object idiom, and that should make their objects a bit easier for you to use. Finally, one promising use of this idiom is that it can serve as a starting point for discussion when formulating Java coding standards for a project or organization.

Implementation guidelines

Here are some guidelines to help you make the most of the canonical object idiom:

Make objects canonical by default
In general, you should implement the canonical object idiom in every Java class you define, unless you have a specific reason not to. Although you may not be able to imagine why someone would want to use a particular class of objects in some of these ways, you have likely met coworkers who are capable of surprising you in how they use your classes. Besides, predicting the future is a difficult business. One of these days even you may reuse your classes in some ways you didn't imagine when you first designed the class.

The benefit of canonical objects is that they are more flexible (easy to understand, use, and change) than their non-canonical brethren. Canonical objects help make code flexible because they are ready to be manipulated in the ways objects of any type are commonly manipulated. By now you know that canonical objects can be cloned, serialized, and semantically compared with equals, but they can also be used in other common ways. Invoking toString() on a canonical object will yield a reasonable result provided by the default implementation of toString() in superclass Object. Likewise, hashCode() works properly thanks to Object's default implementation. getClass() returns a reference to the appropriate Class instance, and even the wait() and notify() methods work. Everything works. Canonical objects are ready to do what you want them to do.

Catch CloneNotSupportedException
The customary first step in any implementation of clone() is to invoke the superclass's implementation of clone(). If you are writing a clone() method for a direct subclass of class Object, you will need to either catch CloneNotSupportedException or declare it in your throws clause. If you forget to do either of these two things, the compiler will dutifully inform you of your negligence.

So, given that the compiler will force you to deal with CloneNotSupportedException in one way or the other, which way should you deal with it? In general, you should catch CloneNotSupportedException and throw some kind of unchecked exception in the catch clause, the approach demonstrated by the Worker class. Why? Because if you declare CloneNotSupportedException in your throws clause, anyone who wants to clone your object will need to deal with the exception -- either by catching it or declaring it in their throws clause. And you don't want to bother clients of your class with all that hard decision-making just because they want to clone your object.