Effective Java Chapter 3

Chapter 3. Methods common to all objects

• This chapter focuses on how to override Objects methods.

10. equals overrides should be subject to general contracts

• General contracts are reflexive, symmetric, transitive, consistent, and non-null.
• If you use google's AutoValue, it will override equals well.

11. If you override equals, also override hashcode

• According to the general contract for hashCode, two equal objects must return equal hashCode values. Therefore, if you override equals and assume that they are logically equal but not the same reference, they will return different values than if you did not override hashCode.

• If you care about performance, cache the value calculated by hashCode.

12. Always override toString

• The toString of Thread.java is as follows.

    public String toString() {
        ThreadGroup group = getThreadGroup();
        if (group != null) {
            return "Thread[" + getName() + "," + getPriority() + "," +
                           group.getName() + "]";
        } else {
            return "Thread[" + getName() + "," + getPriority() + "," +
                            "" + "]";
        }
    }

13. Be careful when overriding clone

• Call super.clone to cast. If there is a mutable variable, deep copy it.

• In most cases, it's easier to make a copy of an object with a constructor or factory method than with a clone method. The only thing that clones is better at copying arrays.

14. Consider implementing Comparable

• Java library value classes, including enums, generally implement Comparable.
• Regarding BigDecimal, BigDecimal ("1.0") and BigDecimal ("1.00") are treated differently in equals, but they are treated the same in compareTo. Therefore, when you put these two in HashSet, two elements remain, but when you put them in TreeSet, they become one.
• In compareTo, comparing using the inequality sign is redundant and can cause errors, so you should use the primitive wrapper class compare.
• When considering sorting with multiple keys, consider using Comparator's construction method. It seems that this is better than comparing one by one and dividing by if statement.

package tryAny.effectiveJava;

import static java.util.Comparator.*;
import java.util.Comparator;
import java.util.stream.Stream;

public class CompareTest {
    public static void main(String[] args) {
	Stream<PhoneNum> s = Stream.of(new PhoneNum(111, 222, 333), new PhoneNum(111, 222, 222),
		new PhoneNum(111, 333, 111), new PhoneNum(000, 999, 1));
	s.sorted().forEach(System.out::println);
    }
}

class PhoneNum implements Comparable<PhoneNum> {
    int areaCode;
    int prefix;
    int lineNum;

    public PhoneNum(int areaCode, int prefix, int lineNum) {
	this.areaCode = areaCode;
	this.prefix = prefix;
	this.lineNum = lineNum;
    }

    private static final Comparator<PhoneNum> COMPARATOR = comparingInt((PhoneNum pn) -> pn.areaCode)
	    .thenComparingInt(pn -> pn.prefix).thenComparingInt(pn -> pn.lineNum);

    @Override
    public int compareTo(PhoneNum pn) {
	return COMPARATOR.compare(this, pn);
    }

    @Override
    public String toString() {
	StringBuilder sb = new StringBuilder();
	sb.append("areaCode:").append(areaCode).append(",prefix:").append(prefix).append(",lineNum:").append(lineNum);
	return sb.toString();
    }
}