java - equals method calling a setter, is there anti-pattern documentation?

Question

Is there any documentation that states that the "equals" method should NOT call a "setter"?

I am politely asking for ~documentation~, not opinions. To satisfy SOF guidelines about asking opinion questions.

I don't "see" it in the oracle documentation.

https://docs.oracle.com/javase/8/docs/api/java/lang/Object.html#equals-java.lang.Object-

public boolean equals(Object obj) Indicates whether some other object is "equal to" this one. The equals method implements an equivalence relation on non-null object references:

It is reflexive: for any non-null reference value x, x.equals(x) should return true.

It is symmetric: for any non-null reference values x and y, x.equals(y) should return true if and only if y.equals(x) returns true.

It is transitive: for any non-null reference values x, y, and z, if x.equals(y) returns true and y.equals(z) returns true, then x.equals(z) should return true.

It is consistent: for any non-null reference values x and y, multiple invocations of x.equals(y) consistently return true or consistently return false, provided no information used in equals comparisons on the objects is modified. For any non-null reference value x, x.equals(null) should return false.

The equals method for class Object implements the most discriminating possible equivalence relation on objects; that is, for any non-null reference values x and y, this method returns true if and only if x and y refer to the same object (x == y has the value true).

Note that it is generally necessary to override the hashCode method whenever this method is overridden, so as to maintain the general contract for the hashCode method, which states that equal objects must have equal hash codes.

Parameters: obj - the reference object with which to compare. Returns: true if this object is the same as the obj argument; false otherwise. See Also: hashCode(), HashMap

question from:https://stackoverflow.com/questions/65919478/equals-method-calling-a-setter-is-there-anti-pattern-documentation

Answer 1

First, ask yourself - why do you want to do that? - and then, look for a mistake in the answer.

You do not need (and, mostly, you will not find) a documentation enumerating things, that should/can not be done with/on a particular entity; rather, documentations say what should be done and - how.

Yes, there are some exceptions to the above definition, and sometimes documentations explicitly state, that (1) "you should better avoid x!" or (2) "unfortunately you cannot do y!"; but these usually happen when (1) some concepts are a bit equivocal, ambiguous, overlapping/cross-responsible, and they can be interpreted in a number of ways; or (2) when something seems achievable, at a glance, but it is not.

For example, .equals(Object o), can be!, but:

1. should not be used to get/set the state;
2. should not be used to calculate the hash;
3. should not be used to do the RPC/Rest call;

and these should not points (thankfully) are not documented, because, since the Java 1.0 (January 1996), .equals(Object o) method has always had a single, very clear and sharp responsibility and purpose: to assert the equality of two objects, and it will continue to have that, same, sole purpose in the future, thanks to the backwards compatibility.

.equals(Object o) should not even be the matter of reasoning, whether shall we use this to set the state?, because for this, setters exist; hence - there is no documentation, that it can/should not be used for setting the state; however, it Certainly(!) should not be used for setting the state, as again - it has another purpose - to solely check the equality of this, and given (o) objects.

In addition, in a lot of the cases, you will need to @Override .equals(Object o) to do the corresponding comparison of your custom objects. So, how will you mix the setter and equals, both in one method? you will end up in a maintainability and readability hell.

Stick with Single Responsibility Principle.

Stick with Clean Code Principles and make your methods short, concise, working on a single, clear, and intuitively understandable unit of the functionality.

Stick with KISS principle and do not try to make your car fly, and your helicopter - swim.

Think about readability, extensibility and maintainability of the class, where you override .equals(Object o) to set the state; it will be hell. If I, personally, would see such a thing, I will start to doubt, that the author of this code could have written getters for setting and setters for getting.