   Java search/find by conditional?
  If I have some Collection (say, an ArrayList) and I want to get an element from it using some condition other than "result == element_to_find", how would I go about doing that? Specifically, I have a class that implements equals and I would like to search using that rather than whatever Java is doing at the moment, i.e. I would like it to return an element such that "result.equals(element_to_find)".The documentation suggests that's what it's doing, but when searching etc., no statements in 'equals' get called.   
  Conceivably you need to implement a HasTestForEqualsForUseInSearching interface, or something similarly obvious?   ;  Make sure that you're properly overriding the "equals" method. It expects an argument of type "object", so if you write this:...public boolean equals(MyClass obj){....then it won't call your version.Also, this is a great place to use the @Override annotation.   ;  Ah, spot on. So, if I'm now accepting an object rather than my class, is it ok to cast it to my class to check for equality?   ;  The standard idiom goes something like this:public boolean equals(Object o){    if (!(o instanceof MyClass)) return false;    MyClass c = (MyClass) o;    // perform comparison on c}Don't forget to override hashCode! You always have to do this if you override equals in order to insure the contract that equal objects must have the same hashcode.;Quote:Original post by DevFredThe standard idiom goes something like this:public boolean equals(Object o){    if (!(o instanceof MyClass)) return false;    MyClass c = (MyClass) o;    // perform comparison on c}Of course, if you are *expecting* MyClasses to be compared only to each other, you can do it like:public boolean equals(Object o){    try {   MyClass c = (MyClass) o;   // perform comparison on c    } catch (ClassCastException cce) { return false; }}This is *presumably* faster when working mostly with homogenous collections, and slower when trying to use Java like a dynamically typed language, but as always, profile :)Quote:Don't forget to override hashCode! You always have to do this if you override equals in order to insure the contract that equal objects must have the same hashcode.QFE.Quote:Original post by KingOfMenConceivably you need to implement a HasTestForEqualsForUseInSearching interface, or something similarly obvious?The only interface close to that which I can think of is called Comparable, and it consists of one function: int compareTo(Object). If your objects are *sort*able, then you would implement that function to give the default sort order. This usually *should* throw an exception if the other Object is of the wrong type (how exactly do you want to sort a heterogeneous container, anyway?), so best to just let the exception propagate there. Then you can implement .equals in terms of that:public int compareTo(Object o) {    MyClass c = (MyClass) o;    // perform three-way comparison and return an appropriate value:    // negative if this < o, zero if this == o, positive if this > o}public boolean equals(Object o) {    try {   return compareTo(o) == 0;    } catch (ClassCastException cce) { return false; }}public int hashCode() {    // Needs to return something such that    // (this == o) => (this.hashCode() == o.hashCode()) [always!]    // (this.hashCode() == o.hashCode()) =/> (this == o)    // [but it should *usually* turn out that way, though not guaranteed.]    // If your comparison is based on comparing one int, for example, you could    // just return that member.}But all you need for *searching* is .equals() and .hashCode(), and those are defined all the way up in java.lang.Object (though you still have to override them: the default .hashCode basically returns the object's "address in memory" - whatever that means in Java - and the default .equals compares those values; i.e. it checks for object *identity*). :)   