Re: Distinct ID Number Per Object?
Hal Vaughan wrote:
Lew wrote:
Hal Vaughan wrote:
The part that concerned me was this: "It is not required that if two
objects are unequal according to the equals(java.lang.Object) method, then
calling the hashCode method on each of the two objects must produce
distinct integer results."
That's why I was asking about whether they were unique within a particular
runtime.
They aren't, necessarily. It depends on the hashCode() method of the object
in question.
You certainly cannot rely on a correspondence. That is what Sun's
implementation of Object.hashCode() does, but many, many subclasses
override
it.
It's in one of my own classes, so I'm not concerned about it being
overridden.
I don't understand. If you control the hashCode() then you know what it does.
Where does the question come from?
It is a best practice (see /Effective Java/ by Josh Bloch) to
override
hashCode() in any class that overrides equals().
That part I did find, but I won't be overridding either one.
Since most of the
objects in an application likely are of subtypes of Object, it is common
that their hashCode() will not return the "address" of the object.
I don't need to separate all objects. I have a set of data tables that all
have a master table, but then they have sub tables that are tracked subsets
of the master tables. I need to make sure that if I create a tracked
table, it has a different name from all the other tracked tables. I have
one particular class that will be generating names for those tracked tables
on its own and I want to make sure that if I create, say, 5 instances of
that class, that each separate instance will create names that are
different than the names created by the other instances.
But names aren't hash codes. By definition, a hash reduces the size of the
value set from the domain to the range.
I don't need an object's address or anything, I just want to be sure that
each instance of this one class has some kind of unique ID I can use to
specify unique names for the tracked tables.
So create unique names. Your issue has nothing to do with hashCode().
If you override equals, let's say to guarantee that two objects with the same
name are considered equal, i.e., to "mean" the same real-world object (in your
case, a "table"), then also override hashCode().
Why not just override those methods so that any time two objects with the same
name, which may be different objects in the JVM, are understood to refer to
the same table? This is a more normal idiom and should do everything you
need. Then you can use normal Maps to map the name to the object that models
the table.
class TableModel
{
private final String name;
public TableModel( String n )
{
name = n;
}
public final String getName() { return name; }
// other attributes
}
then in some other code
Map <String, TableModel> tables = new HashMap <String, TableModel> ();
public TableModel put( TableModel table )
{
return tables.put( table.getName(), table );
}
If you need a table object at a later time in your code, obtain
tables.get( name )
given the name of the table you want. (If you get null, create a TableModel
and put() it into the Map.)
This idiom might save you the trouble of UUID generation.
--
Lew