I remember eclipse and idea have this template to automatically create an object\'s hashCode based on its attributes.
One of the strategies if a number and a string is u
Or, if you don't want to add another library, do something like the following:
public int hashCode() {
StringBuilder builder = new StringBuilder();
builder.append(myString);
builder.append(myInteger);
return builder.toString().hashCode();
}
Use the Apache Commons HashcodeBuilder:
public int hashCode() {
new HashCodeBuilder(17, 37).
append(myString).
append(myInt);
}
Link here: http://commons.apache.org/lang/api-2.3/org/apache/commons/lang/builder/HashCodeBuilder.html
And here:
http://www.koders.com/java/fidCE4E86F23847AE93909CE105394B668DDB0F491A.aspx
A hashcode method is something that potentially be called many times, and is therefore worth optimizing. If the calculation is complicated, consider memoizing the hash value. Also, avoid doing things that entail more calculation than is necessary. (For example, the StringBuilder solution spends most of its time creating the temporary String.)
The other thing I want to point out is that the quality of the hash is important. You want to avoid any hashcode algorithm that maps lots of common keys. If that happens, hash table lookup may no longer be O(1). (In the worst case it will be O(N) ... i.e. equivalent to a linear search!). Here's an example of a bad hash function:
int hashcode() {
int hash = 1;
for (int val : this.values) {
hash = hash * value;
}
return hash;
}
Consider what happens if an element of this.values
is zero ...
Further to your most recent edit, if retrieval speed is more important than storage concerns you could pre-compute and store the hash code when constructing your StringInt
class. This is safe as you've marked the String
and int
fields as final
, and also given that String
is immutable.
Also, you could optimise your equals
method by checking that the object being compared == this
before doing a full comparison. I would also recommend doing the cheaper int-based comparison first before comparing the string fields.
Another final suggestion: You could change your valueOf(String, int)
method to either construct a StringInt
or return a previously created instance if one already exists with the same String
and int values. This makes construction more expensive but comparisons very cheap as you can compare StringInt
s using "==" in the knowledge that no two StringInt
s will ever be created with the same String
and int
value.
Eclipse always does roughly the same hashing function, here's an example for a class with an in and String as fields
public int hashCode() {
final int prime = 31;
int result = 1;
result = prime * result + this.interger;
result = prime * result + ((this.string == null) ? 0 : this.string.hashCode());
return result;
}
They always pick 31 as the prime, and then multiple by build in hash functions or the value if its a primitive. Something like this wouldn't be hard to create as a method.
public int hashCode(Object ... things) {
final int prime = 31;
int result = 1;
for(Object thing : things) {
result = prime * result + thing.hashCode();
}
return result;
}
You can also use Objects
class from java.util.Objects
package to quickly get hash code.
@Override
public int hashCode() {
return Objects.hash(this.string, this.integerValue, this.otherDataTypes);
}