Database Reference
In-Depth Information
This method for defining a
Date
with three integers representing year, month, and day is
deprecated
,
which means it is still available but no longer approved for use in code. Potentially, deprecated features
will be removed in future versions of the JDK. I use it here only for illustration purposes. Perhaps the
reason that this
Date
constructor is deprecated is the inconsistency in specifying the integers. This
constructor adds 1900 to the year specification and adds 1 to the month. The month specification is 0-
based (0-11), but the day is 1-based (1-31).
Note that the
BERLIN_WALL_FELL Date
member still points at the same instance of
Date
(we did not
instantiate a new
Date
), but we changed the value. In fact, that member variable meets all the
requirements for a Java constant, but it turned out to be changeable (rather than constant)! So, my advice
is to choose some other, simpler, primitive or immutable type to be a constant, like this
String
:
public static final String BERLIN_WALL_FELL = “November 9, 1989”;
If you must use a mutable class instance as a constant, then I suggest you make it private and have a
getter method that is public. Do not provide a setter method. In addition, recall that when you provide an
object through a getter method, you are passing the reference to the original object, not sending a copy of
the original object to the caller. If you just return your private member, and it is mutable, then the caller
can change it. To avoid this problem, create a new instance of your constant class type by
cloning
the
object, and return the clone (actually return a reference to the clone).
Here is how that all might look:
private static final Date BERLIN_WALL_FELL = new Date( 89, 10, 9 );
public static final Date getBERLIN_WALL_FELL() {
return (Date)BERLIN_WALL_FELL.clone();
}
Because our constant is private, no one can modify it, unless we expose it. We allow people to get its value
through the getter method,
getBERLIN_WALL_FELL()
. However, we don't return a reference to our
constant, but rather we return a reference to a clone of our constant. We can do that because
Date
implements the
Cloneable
interface. Note that the
clone()
method returns an
Object
, which we have to
cast as a
Date
to return.
The one who calls this getter could always change his personal reference to this
Date
or the value of the
Date
; but even so, each one who calls the original
getBERLIN_WALL_FELL()
method will get a
Date
with
the correct value.
While we're on the subject of the
final
modifier, we should observe that the
getBERLIN_WALL_FELL()
method is declared
final
in the last section. This has a couple of effects. The first idea that we need to be
prepared to adhere to is that anything we call
final
should never change. The primary reason is that
any
code that refers to something we've called
final
will
need to be recompiled if we ever modify our code.
We should consider these
final
methods to be constant methods. (Perhaps we should agree to indicate
this fact by giving our methods all upper case names with underscore characters between words. There is
no convention for that, yet.) The exceptions to this idea of recompiling all referencing code are difficult to
identify, so this idea is like a
rule
you should follow.
