我应该总是覆盖 equals、hashcode 和 toString 方法吗？

Question

I have rather simple question: According to best programming practices, when I create a new model class should I always override equals, hashcode and toString methods? Even I do not intend to compare objects of specific class?

Answer 1

Each of these methods has its own significance. equals and hashCode methods are used for comparison and hashing and toString mainly for logging purposes. If you don't want any of these functionalities, you are not required to implement them.

Answer 2

Another best practice is to not implement code that is never used. So implement those methods mostly on demand. One reason to implement those methods without using them right away would be to assure a specific implementation or behaviour which one other developer maybe could not be aware of when he implements it on demand. So for your question: No, not always.

Answer 3

Even though above answers are correct, I would like to add on why these methods are actually overridden. If your model class will be used as a key of a Map or a Tree , or in a Set , its best practice to override equals and hashCode method (as it will be needed for comparing 2 model class objects).

toString you will need to override, if you want you want to display your model class data in a efficient way. Suppose if you have a model class, Dummy , having 2 fields, field1 and field2 .

// Without overriding toString
System.out.println("field1: " + dummyObj.field1 + " field2"+dummyObj.field2);

// With overriding toString
System.out.println(dummyObj);

// Your overridden toString
public String toString(){
  return "field1: " + this.field1 + " field2"+this.field2;
}

Answer 4

As per my own perspective

You should not override always hashcode and equal but you should override toString

why toString?

say you have a class with more than 10 properties and you are debugging an object that it is populated or not,

I would prefer to not check through getter instead print out an object will reduce my time

hashcode and equal?

these two methods come into the picture whenever we use hash-based collection like:

(1) hashSet, (2) hashTable, (3) hashMap and few more

if you are not intended to use collection and comparing of an object! then you just have useless code which creates ambiguity

Answer 5

The decision should be based on

• consistency (guide lines, and code checkers)
• quality
• code style
• effort (writing, reading & understanding implications)

I myself am rather lax, feeling that not every class needs that much of attention (for a possible future use).

Though guide lines should be followed stoically. Code checkers almost never be ignored.

As IDEs and even libraries provide easily created boiler code for generating the methods, the effort is low, but the code style can become unnecesarily bloated. Especially for inner classes.

And of course "callback" event handling classes do not need them.