Advertisement

Summary
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 Object.

As a Java programmer, you can treat an object as an Object 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 which are clone(), equals(), toString(), wait(), notify(), finalize(), getClass(), and 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 uniformly as Objects.

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."