Security Director at ForgeRock.
Author: https://www.manning.com/books/api-security-in-action
Cryptography and application security. PhD in AI. Secret Prolog junkie.
My favourite approach is to implement Comparable<T> then make equals just do:
public boolean equals(Object that) {
return this == that
|| that instanceof T && this.compareTo((T) that) == 0;
}
Isn't always applicable but ensures compareTo is consistent with equals when you want to implement both anyway. Otherwise I write an isEqualTo(T that) method and do similar.
Yeah, I tried to implement isEqualTo(), but I end up with a bunch of nice short methods, that do not belong to my class, and that doesn't look nice. Where should I put it? It would be nice to have some mixin, but I cannot override equals() there, and in that case there will be equals() that calls some methods that I do not see, and by some magic, it later calls isEqualTo().
I like idea with Comparable. It makes sense, but in some situations it is an overkill, I agree.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
My favourite approach is to implement
Comparable<T>then make equals just do:Isn't always applicable but ensures compareTo is consistent with equals when you want to implement both anyway. Otherwise I write an
isEqualTo(T that)method and do similar.Yeah, I tried to implement
isEqualTo(), but I end up with a bunch of nice short methods, that do not belong to my class, and that doesn't look nice. Where should I put it? It would be nice to have some mixin, but I cannot overrideequals()there, and in that case there will beequals()that calls some methods that I do not see, and by some magic, it later callsisEqualTo().I like idea with
Comparable. It makes sense, but in some situations it is an overkill, I agree.