2

Is there any design pattern (or idiom) that helps to implement equals() method in Java?

That task is'n so hard but in most cases it's about the same... That's why I guess that there is a pattern but I didn't find it.

UPDATE

I chose the method: generate equals() method in Eclipse but... I found a good way (in AbstractList) to make that generated code better: 

if (!(attributes ==null ? other.attributes==null : attributes.equals(other.attributes))) 
    return false;

instead of generated:

if (attributes == null) {
        if (other.attributes != null)
        return false;
    } else if (!attributes.equals(other.attributes))
        return false;
Improve this question
2
  • 3
    Have a look at this: artima.com/lejava/articles/equality.html Commented Oct 11, 2012 at 6:46
  • I was about to post the same link. Put special attention to #4, because it is often overlooked in other articles. Commented Oct 11, 2012 at 6:50

7 Answers 7

Reset to default
4

Generally to implement equals() method, what I do is : I generate those from Eclipse as Eclipse can generate hashCode, toString and equals() methods very well.

Improve this answer
Sign up to request clarification or add additional context in comments.

2 Comments

It would be more helpful for him if you explain more on how to customize equals() and hashcode(), toString() method generation in eclipse.
While I default to using the code generated by my IDE (Intellij), I immediately refactor the generated equals() method to bring it up-to-date with later versions of Java (14+): stackoverflow.com/a/75402885/501113
3

I always use following code:

if (null == obj) return false;
if (this == obj) return true;
if (!(object instanceof MyClass)) return false;
MyClass that = (MyClass) obj;
EqualsBuilder eb = new EqualsBuilder();
eb.append(this.businessKey, that.businessKey);
return eb.isEquals();

...

I never use technical keys like sequences or pk's, always business fields. Therefore I don't believe this can be made generic but must be made specific to any given Class.

Improve this answer

1 Comment

if obj is null then the instanceof test will fail - so you can trim this down even more :)
1

It is pretty much up to yourself to decide when two object are "the same" in a certain sense... Should they be equal when they contain the same data (perfectly valid usecase) or more strictly when they are the same physical object in memory (also valid) or just the same row in a DB when compared in a clustered environment?

Just remember to also override .hashCode() or you're in for a world of hurt :-)

(Also, good article suggestions from @Andreas and @flash.)

Cheers,

Improve this answer

Comments

1

Maybe this helps: Implementing equals. Especially be aware of the close relationship betweeen hashcode() and equals(). Other than that, I suppose the concrete implementation of equals() really depends on your class design, means when do you treat two objects equal.

Improve this answer

Comments

1

Look at what Java Language Specification got to say.

equals method just defines the notion of object equality

Apart from that there is no design pattern involved in designing this method. The truth is that equals method is already designed by Java language designers and you can only make use of the design. If you are not confident of how to write your own equals method, consider taking the help of IDE's like eclipse which does the job for you.

Improve this answer

1 Comment

There is a well-known contract regarding implementing equals() outlined in the book by Joshua Bloch, "Effective Java, Third Edition". And there are even newer more effective implementations based on Java 14+: stackoverflow.com/a/75402885/501113
1

Regarding adding equals and hashCode for JPA/Hibernate entities, please see this StackOverflow Answer.

The code pattern recommended below depends upon the new instanceof pattern matching functionality released for preview in Java 14 (2020/Mar/17), and then fully released in Java 16 (2021/Mar/16).

I really dislike seeing explicit uses of true and false, especially when they fall directly out of evaluated logic.

So, I am not at all fond of the default code pattern generated by my IDE (IntelliJ) when overriding and implementing equals() in my classes.

It looks like this:

//Legacy laden pattern produced by IntelliJ code generator
public boolean equals(Object o) {
  if (this == o) {
    return true;
  }
  if (o == null || getClass() != o.getClass()) {
    return false;
  }
  EqualsExampleClass that = (EqualsExampleClass) o;
  return Objects.equals(stringy, that.stringy)
      && (inty == that.inty)
      && Objects.equals(bigIntegery, that.bigIntegery)
      && (booleany == that.booleany);
}

Encouraged by Oracle JEP 394 for the instanceof pattern matching, I've refactored the above code to look like this:

//Modern flowing fluent style
@Override
public boolean equals(Object o) {
  return (this == o) ||
      ((o instanceof EqualsExampleClass that)
          && (this.getClass() == that.getClass())
          && Objects.equals(this.stringy, that.stringy)
          && (this.inty == that.inty)
          && Objects.equals(this.bigInt, that.bigInt)
          && (this.booleany == that.booleany));
}

Per line execution details:

  1. (this == o) - checks for literally the same instance
  2. (o instanceof EqualsExampleClass that) - checks to ensure o is not null, o is an instance of this class (or a descendant), and if so, assigns o to the narrowed type variable that
  3. (this.getClass() == that.getClass()) - requires the equals comparison is between two instances of the same class (i.e., that is not an instance of a descendant class), and can be removed if, and only if, this class is marked final
  4. Objects.equals(this.stringy, that.stringy) - is using Objects.equals() on references (not primitives) to ensure that if either side returns a null, the comparison is successfully made without throwing a NullPointerException

This code implementation pattern is considerably easier to functional flow read, analyze, reason about, and debug, during a refactoring pass.

Improve this answer

3 Comments

The JEP you refer to is using instanceof inside the equals method of a final class. I am assuming your example class is not, and so you add the getClass() check. TBH, adding both in the same equals method is almost painful to read. And I don't personally find that the "double-nested fluent" style easier to read, for this example at least, which is an opinion that could be influenced by all the redundant parenthesis you add.
Agreed regarding final. And from what I can tell given your JPA/Hibernate answer, I tend to agree with ALL of your thinking in this area. I do get the fluent style is not for everyone. I am coming from Scala, so it reads so much cleaner than the traditional Java stuff I used to do in Java myself (been doing Java since 1996), before I began using Scala as my primary language in 2014. I've been back in Java now for a year. Hence, my answer. Old me prior to Scala wouldn't have liked the fluent functional style.
hahahaha yes, isn't marvelous, how programming is based on so much emotions after all 😂 And I like it. We all just have to remind ourselves that our opinion today is not what it was yesterday, and it may very well change tomorrow. Over the years, certain elements of my programming style has changed a numerous amount of times, some times back and forth 😂
-1

Not sure about your expectation. equals() is meant for defining your criteria of comparing two different objects of your class for equality.

In general, you compare each attribute one by one but its very much possible and supported that you do the comparison using fewer selected attributes only.

Improve this answer

Comments

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.