|
|
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
Page 2 of 5
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.
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.