Re: collection framework: using the good interface

SL wrote: 
Hi,

I have a collection of objects containing information about words: each object hold a word, its part of speech (verb, noun, etc.), its frequency, and other properties.

I need to be able to retreive very quickly an objet according to some signifiant properties: its orthographic form and its part of speech for instance. A hash seems suited, but I cannot use a hash where the key is the orthographic form, for instance:
{
"plane" -> ref_to_object_holding_this_word
}

because several properties are signifiant for word identity: there is a plane "noun" and a plane "verbe".

If you want to retrieve by several different properties, and do it efficiently for each of them, you need several different index structures.

How about a series of HashMap instances, one for each property? Each HashMap would use a property as key, with the set of full objects sharing a given key as value.

For example, to search for all nouns you would go to a HashMap indexed by part of speech, and retrieve the set for noun.

If you don't care about efficiency for some or all of the properties, you can just iterate over a Set of all the objects asking each of them "are you a noun?".


Implementing hashkey() and equals() in my Word object seems to be the natural way, with "orthographic form" and "part of speech" fields both contributing to the definition of hashkey and equality, but in that case I would have a Map where both the key and the corresponding value are references to the same object. I'm wondering if this situation should be avoided, and if there is another solution. Since key and value are not different object, I was considering using an ArrayList object. But its indexOf(Object elem) method use equals() and not hashkey, and is probably not as much efficient as the HashMap hashing method.

Thanks,
SL

I would not override hashCode and equals for this, because there isn't a single, fixed definition of equality between two of your word-representing objects other than identity.

Patricia
.

Relevant Pages