아이템 10: equals는 일반 규약을 지켜 재정의하라

equals 메서드를 재정의하지 않아도 되는 상황

1. 각 인스턴스가 본질적으로 고유하다 — 값을 표현하는게 아니라 동작하는 개체를 표현하는 클래스가 여기에 해당함(Thread가 좋은 예)

2. 인스턴스의 논리적 동치성을 검사할 일이 없다 — 예로, Pattern의 equals를 재정의하여 두 정규표현식이 같은 것인지를 검사하는 경우. 이런 경우가 없다면 Object의 equals만으로 충분함

3. 상위 클래스에서 재정의한 equals가 하위 클래스에도 딱 들어맞는다. — Set의 구현체는 AbstractSet의 equals를 상속받아 쓰고, List 구현체들은 AbstractList로부터..
1. equals 메서드를 추상클래스에서 정의가 가능함. interface는 Object의 메서드를 오버라이드 할 수도 없고

4. 클래스가 private이거나 package-private이고 equals 메서드를 호출할 일이 없다.

equals를 재정의해야 될 때 ? (주로 값 클래스들,VO,이 해당)

• 객체 식별성(object identity; 두 객체가 물리적으로 같은가)이 아닌 논리적 동치성을 확인해야 하는데 상위 클래스의 equals가 논리적 동치성을 비교하도록 재정의되지 않았을 때

• 논리적 동치성을 확인하도록 재정의 해 두었을 때, Map의 키와 Set의 원소로도 사용할 수 있음

• 값 클래스라 해도 굳이 equals를 정의하지 않아도 될 때
• 인스턴스 통제 클래스로 인해 같은 인스턴스가 둘 이상 만들어지지 않을 때
• Enum이 위의 사례에 해당됨. 어차피 논리적으로 같은 인스턴스가 2개 이상 만들어지지 않으니 논리적 동치성과 객체 식별성이 사실상 똑같음

equals 메서드를 재정의할 때 따라야 할 일반 규약

반사성(reflexivity)

• null이 아닌 모든 참조 값 x에 대해 x.equals(x)는 true다

• 단순히 말하면 객체는 자기 자신과 같아야 한다는 의미 → 이 요건을 어긴다면 인스턴스를 컬렉션에 넣은 다음 contains 메서드를 호출하면 방금 넣은 인스턴스가 없다고 답할 것임

대칭성(symmetry)

• 두 객체는 서로에 대한 동치 여부에 똑같이 답해야 한다

public final class CaseInsensitiveString {
    private final String s;

    public CaseInsensitiveString(String s) {
        this.s = Objects.requireNonNull(s);
    }

    // 대칭성 위배!
    @Override public boolean equals(Object o) {
        if (o instanceof CaseInsensitiveString)
            return s.equalsIgnoreCase(
                    ((CaseInsensitiveString) o).s);
        if (o instanceof String)  // 한 방향으로만 작동한다!
            return s.equalsIgnoreCase((String) o);
        return false;
    }

    // 문제 시연 (55쪽)
    public static void main(String[] args) {
        CaseInsensitiveString cis = new CaseInsensitiveString("Polish");
        String s = "polish";

        List<CaseInsensitiveString> list = new ArrayList<>();
        list.add(cis);

        System.out.println(list.contains(s)); 
// cis.equals(s) 는 true인데 반해 list.contains(s)는(s.equals(?)) false를 반환함
    }


//    // 수정한 equals 메서드 (56쪽)
//    @Override public boolean equals(Object o) {
//        return o instanceof CaseInsensitiveString &&
//                ((CaseInsensitiveString) o).s.equalsIgnoreCase(s);
//    }
}

• cis.equals(s) 는 true인데 반해 list.contains(s)는(s.equals(?)) false를 반환함

• CaseInsensitiveString과 String을 비교하려는 꿈을 접자

추이성(transitivity)

• 첫 번째 객체와 두 번째 객체가 같고 두번째 객체와 세 번째 객체가 같다면 첫 번째 객체와 세번째 객체도 같아야 한다는 뜻

package effectivejava.chapter3.item10.inheritance;

import effectivejava.chapter3.item10.Color;
import effectivejava.chapter3.item10.Point;

// Point에 값 컴포넌트(color)를 추가 (56쪽)
public class ColorPoint extends Point {
    private final Color color;

    public ColorPoint(int x, int y, Color color) {
        super(x, y);
        this.color = color;
    }

    // 코드 10-2 잘못된 코드 - 대칭성 위배! (57쪽)
    @Override public boolean equals(Object o) {
        if (!(o instanceof ColorPoint))
            return false;
        return super.equals(o) && ((ColorPoint) o).color == color;
    }

//    // 코드 10-3 잘못된 코드 - 추이성 위배! (57쪽)
//    @Override public boolean equals(Object o) {
//        if (!(o instanceof Point))
//            return false;
//
//        // o가 일반 Point면 색상을 무시하고 비교한다.
//        if (!(o instanceof ColorPoint))
//            return o.equals(this);
//
//        // o가 ColorPoint면 색상까지 비교한다.
//        return super.equals(o) && ((ColorPoint) o).color == color;
//    }

    public static void main(String[] args) {
        // 첫 번째 equals 메서드(코드 10-2)는 대칭성을 위배한다. (57쪽)
        Point p = new Point(1, 2);
        ColorPoint cp = new ColorPoint(1, 2, Color.RED);
        System.out.println(p.equals(cp) + " " + cp.equals(p)); // true  false

        // 두 번째 equals 메서드(코드 10-3)는 추이성을 위배한다. (57쪽)
        ColorPoint p1 = new ColorPoint(1, 2, Color.RED);
        Point p2 = new Point(1, 2);
        ColorPoint p3 = new ColorPoint(1, 2, Color.BLUE);
        System.out.printf("%s %s %s%n",
                          p1.equals(p2), p2.equals(p3), p1.equals(p3));
        // true true false
    }
}

구체 클래스를 확장해 새로운 값을 추가하면서 equals 규약을 만족시킬 방법은 존재하지 않는다! → 우회방법으로 컴포지션을 사용하는 방법이 있긴 해

• 또한 추상클래스의 하위 클래스라면 equals규약을 지키면서도 값을 추가할 수 있음(상위 클래스를 직접 인스턴스로 만드는 게 불가능한 상황이라면 문제 발생 안함!)

package effectivejava.chapter3.item10.composition;

import effectivejava.chapter3.item10.Color;
import effectivejava.chapter3.item10.Point;

import java.util.Objects;

// 코드 10-5 equals 규약을 지키면서 값 추가하기 (60쪽)
public class ColorPoint {
    private final Point point;
    private final Color color;

    public ColorPoint(int x, int y, Color color) {
        point = new Point(x, y);
        this.color = Objects.requireNonNull(color);
    }

    /**
     * 이 ColorPoint의 Point 뷰를 반환한다.
     */
    public Point asPoint() {
        return point;
    }

    @Override public boolean equals(Object o) {
        if (!(o instanceof ColorPoint))
            return false;
        ColorPoint cp = (ColorPoint) o;
        return cp.point.equals(point) && cp.color.equals(color);
    }

    @Override public int hashCode() {
        return 31 * point.hashCode() + color.hashCode();
    }
}

일관성(consistency)

• 두 객체가 같다면(어느 하나 혹은 두 객체 모두가 수정되지 않는 한) 앞으로도 영원히 같아야 한다는 의미

• 클래스가 불변이든 가변이든 equals의 판단에 신뢰할 수 없는 자원이 끼어들게 해서는 안된다. ⇒ 항시 메모리에 존재하는 객체만을 사용한 deterministic 한 계산만 수행해야함
• 예로 java.net.URL의 equals는 주어진 URL과 매핑된 호스트의 IP 주소를 이용해 비교함
• 호스트 이름을 IP 주소로 바꾸려면 네트워크를 통해야 하는데 그 결과가 항상 같다고 보장 못함

null-아님

• 모든 객체가 null과는 같지 않아야 한다는 의미임

//명시적 null 검사 - 필요 없다!   >??
@Override
public boolean equals(Object o){
		if(o == null)
				return false;
}

// 묵시적 null 검사 - 이쪽이 낫다.
@Override
public boolean equals(Object o){
		if(!(o instanceof MyType))
			return false;
		...
}

내용 정리

1. == 연산자를 사용해 입력이 자기 자신의 참조인지 확인하기

2. instanceof 연산자로 입력이 올바른 타입인지 확인한다

• 이 때 올바른 타입은 equals가 정의된 클래스인 것이 보통이지만 가끔은 그 클래스가 구현한 특정 인터페이스가 될 수 있음

• 어떤 인터페이스는 자신을 구현한 (서로 다른) 클래스끼리도 비교할 수 있도록 equals 규약을 수정하기도 함

3. 입력을 올바른 타입으로 형변환한다

4. 입력 객체와 자기 자신의 대응되는 ‘핵심’필드들이 모두 일치하는지 하나씩 검사한다.

• 모든 필드가 일치하면 true를 하나라도 다르면 false

• 2단계에서 인터페이스를 사용했다면 필드 값 접근시 인터페이스 메서드 사용(getter)

• 필드 비교 시
• 기본 타입 필드는 == 연산자로 비교
• 참조 타입 필드는 각각의 equals 메서드로 비교
• float와 double은 각각의 정적 메서드인 Float.compare 와 Double.compare 로 비교 (Float.NaN, -0.0F, 특수한 부동소수 값을 다뤄야 하기 떄문)
• 때로 NULL 도 정상 값으로 취급하는 참조 타입 필드가 있기에 이런 필드는 NullPointerException 방지를 위해 checkArgument(field ≠ null ...)
• 어떤 필드를 먼저 비교하느냐가 equals의 성능을 좌우하기도 함
• 최상의 성능을 바란다면 다를 가능성이 더 크거나 비교하는 비용이 싼 필드 먼저 비교
• 동기화용 락 필드 같이 객체의 논리적 상태와 관련 없는 필드는 비교하면 안됨

마지막 주의사항

• equals 재정의 시 hashCode도 반드시 재정의하기

• 너무 복잡하게 해결하려 들지 말기
• 필드들의 동치성만 검사해도 규약 어렵지 않게 지킬 수 있음
• 일반적으로 alias 부분 비교 안하는게 좋음. File클래스 심볼릭 링크..

• equals의 입력 타입은 반드시 Object여야 함
• 타입을 구체적으로 명시한 equals는 오히려 해가 됨

@Override
public boolean equals(Object o) {
    if (this == o) return true;
    if (o == null || getClass() != o.getClass()) return false;
    Wallet wallet = (Wallet) o;
    return Objects.equal(walletId, wallet.walletId) && Objects.equal(customerId, wallet.customerId) && Objects.equal(voucherId, wallet.voucherId);
}

@Override
public int hashCode() {
    return Objects.hashCode(walletId, customerId, voucherId);
}

package effectivejava.chapter3.item10;

// 코드 10-6 전형적인 equals 메서드의 예 (64쪽)
public final class PhoneNumber {
    private final short areaCode, prefix, lineNum;

    public PhoneNumber(int areaCode, int prefix, int lineNum) {
        this.areaCode = rangeCheck(areaCode, 999, "지역코드");
        this.prefix   = rangeCheck(prefix,   999, "프리픽스");
        this.lineNum  = rangeCheck(lineNum, 9999, "가입자 번호");
    }

    private static short rangeCheck(int val, int max, String arg) {
        if (val < 0 || val > max)
            throw new IllegalArgumentException(arg + ": " + val);
        return (short) val;
    }

    @Override public boolean equals(Object o) {
        if (o == this)
            return true;
        if (!(o instanceof PhoneNumber))
            return false;
        PhoneNumber pn = (PhoneNumber)o;
        return pn.lineNum == lineNum && pn.prefix == prefix
                && pn.areaCode == areaCode;
    }

    // 나머지 코드는 생략 - hashCode 메서드는 꼭 필요하다(아이템 11)!
}