Sponsored Link •
In this installment of the Design Techniques column, I propose "the canonical object" as a Java idiom. The article discusses the fundamental services that all objects in general should offer, shows how objects can offer these services, and names such objects "canonical."
In last month's installment of Design Techniques, I proposed the "event generator" as a Java idiom. This month I will propose another idiom, which I am calling the "canonical object."
I call this object idiom "canonical" because it represents the simplest form an object should take. The idea behind this idiom is to suggest a baseline functionality that you give by default to any object you design. You may adopt this idiom in your own programming practice, or, if you are developing a set of style guidelines for a team or organization, you may want to make the idiom part of those guidelines. The intent of the idiom is not to force programmers to endow every object with this baseline functionality, but simply to define a default functionality for every object. In other words, programmers would be encouraged to make a new object canonical unless they have specific reasons to depart from the idiom in a given, specific case.
A fundamental tenet of object-oriented programming is that you can
treat an instance of a subclass as if it were an instance of a
superclass. Because all classes in Java are subclasses of
java.lang.Object, it follows that another basic tenet of
Java programming is that you can treat any object as, well, an
As a Java programmer, you can treat an object as an
in many ways. When you invoke any of the methods declared in class
java.lang.Object on an object, for example, you are
treating that object as an
Object. These methods, some of
hashCode(), provide basic services commonly exercised on
Java objects of all kinds. In addition, you may find yourself wanting
to serialize just about any kind of object. All of these activities
are ways you may treat objects of many diverse classes simply and
Taken together, all the activities that are commonly performed on Java objects constitute a set of services that, in most cases, should be built into every class you design. The question raised by this article and answered by the idiom is: What do you need to do, at a minimum, to make each object you define support the services commonly expected of all objects?
This idiom defines a baseline set of requirements for object definitions and names objects that implement the baseline "canonical objects."