Re: Distinct ID Number Per Object?
Lew wrote:
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?
I need a unique ID for each instance of the class. Yes, I can control the
hashCode() method, but I wanted to know if it would be unique. At this
point, I've taken Stefan Ram's suggestion and used a static int and each
time an instance is created this int is used as the ID number and the
static int is incremented for the next one.
....
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().
Now I see there are other ways to do this. When I looked through the
Javadocs, the hashCode() function was the only thing I found that I thought
would give a unique id for each class created.
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?
Each table could contain a different subset, so if two objects with the same
name were created, they would use the same table, but they might need
separate tables.
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 I follow this correctly, then one issue is that I have to be sure that
each time an instance of this class is used, I have to make sure it is
passed a unique number as an ID. That means keeping track of those
numbers. I'm using a number of different modules, some I know I'll be
adding months or years from now, so I'm doing as much as possible inside
the classes I'm doing now so later I can create them and use them without
the need to go through much in docs. When I do use them, I will likely
have only a short time to put them in place in a new module, so I'm making
them them as easy as possible to use. Essentially, I'm frontloading the
work. More work now isn't fun, but it means when I have to quickly put
together a new module using these classes, I'll hardly have to remember a
thing or look up much in the Javadocs I create.
Hal