Method common to all objects | chapter III

In here I am going to share what I extracted from Effective Java | 3rd chapter. There may be more imported things for you but in here I am going to share some main points highlighted for me.

In this chapter we discuss about some overridable methods given from java.

Item 10: Obey the general contract when overriding equals

• In default equals method check object is equals to itself.

public boolean equals(Object obj) {
    return (this == obj);
}

There are few things to know before we override the equals method:

1. instanceOf a class is totally unique thing, thats why it check as the default implementation.
2. There is no need for the method to provide a logical equality test. because some java implementation check that equality (ex: java.lang.regex) and some times we have to depend to them.
3. If we override equals on the superclass, then subclasses will follow that implementation and no need to override agin on sub classes.
4. We cannot override toString method when class or package is in private visibility access.
5. And overriding logic is totally depend on the business logic.

Consider about followings when write a unit test :

1. Reflexive:

x, x.equals(x) must return true for non null values. (Object equals to it self.)

2. Symmetric:

x and y, x.equals(y) and y.equals(x) must be true for non null values.

3. Transitive:

x, y, z — if x.equals(y) and y.equals(z), then x.equals(z) must be true.

4. Consistent:

If no info is changed, multiple invocations of x.equals(y) returns the same result each time.

5. Non-nullity:

For any non-null reference value, x.equals(null) must be return false.

For a better equals operator :

• We use equals operator ( == ) to check instances.
• We can check argument type using instanceOf.
• We should consider about fields when we check equality of two objects.
• We have to test ( in unit tests)Symmetric, Transitive and Consistency.

Item 11: Always override hashCode when you override equals

public native int hashCode();

• We have to keep in mind that equals and hashCode both are mostly bounded methods, when we override equals method we should override hashCode, because sometimes equals method may return will false due to hashCode value.
• ex: HashCode, HashTree using hash container concept to identify equal items and if you not override hashCode with equals this hash base Collections will not work correctly.

Item 12: Always override toString

• In default there are many overloaded methods for toString method. IF we consider about method written for objects; will return className@hexString . So there are no more info about objects, thats why we need to override toString method.

public String toString() {
    return getClass().getName() + "@" + Integer.toHexString(hashCode());
}

• And keep your mind that when we override toString method for an object will it effects for future developments, therefore you need to clearly document what you try to do in this override toString method.
• toString method is automatically invoked when an object is passed to println, printf, the string concatenation operator, or assert, or is printed by a debugger.

Item 13: Override clone judiciously

• In JAVA there is a java.lang.Clonable interface and it is a marker interface(an empty interface,[no field or methods]). When we need to clone a class we need to implement that from Clonable interface to identify that class can be clone. But in generally it is one of useless thing in java. Because the only job of Clonable interface is say “this class can clone”.
• If one of class not support for clone (not implemented from Clonable) will throw a ClassNotSupportedException.
• There are three ways of clone. Deep Clone, Shallow Clone, Lazy Clone. And there are few ways to clone objects (using constructor, Using Factory).We can discuss that in later.
• We should not provide clone for immutable classes.

Item 14: Consider implementing Comparable

• We use java.lang.Comparable<T> for check natural order of classes. When we implement from Comparable interface we have to override compareTo method.

public int compareTo(T o);

we return positive integer, if current object is greater than the specific object.

we return negative integer, if current object is less than the specific object.

we return 0, if both current and specific object are in same level. (objects are equal)

This compareTo method will throw classCastException when two objects are not compatible.

And the implementation of comapreTo method is depend on totally business logic and when your class has multiple things to compare, start with the most significant field.

So, these are the highlighted point what I noted-down from the book and some resources.

Resources :

• Books : Effective Java 3rd edition
• YouTube: https://www.youtube.com/c/MarcusBiel
• Web Article: https://dev.to/kylec32/series/2292
• Web Article: https://www.kalebmckelvey.com/blog/effective-java-review-chapter-3-4#what-does-cloneable-interface-do