equals는 일반 규약을 지켜 재정의하라(2) - [3장. 모든 객체의 공통 메서드(아이템10)]

  이번 글에서는 equals 메서드를 재정의할 때 반드시 지켜야 하는 일반 규약 5가지를 조금 더 자세히 알아보고자 한다.

 

1. 반사성(reflexivity)

  A.equals(A) == true

  반사성은 단순히 말하면 객체는 자기 자신과 같아야 한다는 뜻이다. 이 요건은 일부러 어기는 경우가 아니라면 만족시키지 못하기가 더 어려워 보인다.

 

2. 대칭성(symmetry)

  A.equals(B) = B.equals(A)

  대칭성은 두 객체는 서로에 대한 동치 여부에 똑같이 답해야 한다는 뜻이다. 

  대소문자를 구별하지 않는 문자열을 구현한 다음 클래스가 있다고 하자.

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;
    }
}

 

  아래 코드에서 cis.equals(s)는 true를 반환한다는 것을 쉽게 알 수 있다.

  그러면 s.equals(cis)는 어떤 것을 반환할까? CaseInsensitiveString의 equals는 일반 String을 알고 있지만, String의 equals는 CaseInsensitiveString의 존재를 알지 못한다. 그 결과, s.equals(cis)는 false를 반환한다. 이는 대칭성을 명백히 위반하는 것이다. (코드에서 Polish와 polish의 대소문자를 잘 확인하기 바란다.)

CaseInsensitiveString cis = new CaseInsensitiveString("Polish");
String s = "polish";
System.out.println(cis.equals(s)); // true
System.out.println(s.equals(cis)); // false

 

  다른 타입을 지원하기 시작하면 문제가 복잡해지고 대칭성이 깨질 수 있다. 그렇게 때문에 대칭성을 유지하기 위해서는 다른 타입을 지원하지 말아야 한다.

@Override public boolean equals(Object o) {
    return o instanceof CaseInsensitiveString && 
            ((CaseInsenstiveString) o).s.equalsIsIgnoreCase(s));
}

CaseInsensitiveString cis = new CaseInsensitiveString("Polish");
String s = "polish";
System.out.println(cis.equals(s)); // false
System.out.println(s.equals(cis)); // false

 

3. 추이성(transitivity)

  A.equals(B)&&B.equals(C), A.equals(C)

  추이성은 첫 번째 객체와 두 번째 객체가 같고, 두 번째 객체와 세 번째 객체가 같다면, 첫 번째 객체와 세 번째 객체도 같아야 한다는 뜻이다. 

  간단히 2차원에서의 점을 표현하는 클래스가 있다고 해보자.

public class Point {
    private final int x;
    private final int y;
    
    public Point(int x, int y) {
        this.x = x;
        this.y = y;
    }
    
    @Override public boolean equals(Object o) {
        if(!(o instanceof Point))
            return false;
        Point p = (Point)o;
        return p.x == x && p.y == y;
    }
}

 

생각의 흐름 1

  이 클래스를 확장한 색상이 있는 점이 있다고 해보자. 이전까지 배운 것을 바탕으로 equals를 아래와 같이 만들 수 있다. 하지만 이는 다시 대칭성을 지키지 못하는 결과를 초래한다.

public class ColorPoint extends Point {
    private final Color color;
    
    public ColorPoint(int x, int y, Color color) {
        super(x, y);
        this.color = color;
    }
    
    // 대칭성 위배!
    @Override public boolean equals(Object o) {
        if(!(o instanceof ColorPoint))
            return false;
        return super.equals(o) && ((ColorPoint) o).color == color;
    }
}

Point p = new Point(1, 2);
ColorPoint cp = new ColorPoint(1, 2, Color.RED);

System.out.println(p.equals(cp)); // true
System.out.println(cp.equals(p)); // false

 

생각의 흐름 2

  그러면 타입까지 고려하여 만든 equals()는 어떨까? 아래 방식은 대칭성은 지켜주지만, 추이성을 깨버린다. 또한, 이 방식은 무한 재귀에 빠질 위험도 있다. ColorPoint와 같은 레벨에 있는 Point의 서브클래스가 있다면 StackOverflowError가 발생할 것이다.

// 추이성 위배!
@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;
}

ColorPoint p1 = new ColorPoint(1, 2, Color.RED);
Point p2 = new Point(1, 2);
ColorPoint p3 = new ColorPoint(1, 2, Color.BLUE);

System.out.println(p1.equals(p2)); // true
System.out.println(p2.equals(p1)); // true
System.out.println(p1.equals(p3)); // false (true가 나와야지 추이성이 지켜지는 것)

 

생각의 흐름 3

  그러면 추이성을 보장하기 위해서 Point와 ColorPoint를 비교할 때 다르다고 나오면 되지 않을까라고 생각할 수 있다. (p2.equals(p1)이 false가 된다는 말이다.) 그리고 Point 클래스의 코드를 아래와 같이 바꿔볼 수도 있다. 즉, Point는 Point끼리, ColorPoint는 ColorPoint끼리 비교해야 한다는 개념이다.

public class Point {
    private final int x;
    private final int y;
    
    public Point(int x, int y) {
        this.x = x;
        this.y = y;
    }
    
    // 리스코프 치환 원칙 위배!
    @Override public boolean equals(Object o) {
        if(o == null || o.getClass() != getClass()) // 바뀐 부분
            return false;
        Point p = (Point)o;
        return p.x == x && p.y == y;
    }
}

 

  아쉽게도 이렇게 생각하면 안 된다! 이유는 리스코프 치환 원칙에 위배되기 때문이다. 리스코프 치환 원칙을 간단하게 설명하자면, 상위 클래스 타입으로 동작하는 어떤 코드가 있을 때, 그 상위 클래스 대신에 어떤 하위 클래스 타입의 인스턴스를 주더라도 그대로 동일하게 동작해야 한다는 것이다. 아래 코드에서 리스코프 치환 원칙이 위배된다는 것을 확인할 수 있다.

  즉, 구체 클래스를 확장해 새로운 값을 추가하면서 equals 규약을 만족시킬 방법은 존재하지 않는다. 이러한 상황에서 추이성과 대칭성을 위반하지 않도록 equals를 만들 수 없다. (객체 지향적 추상황의 이점을 포기하지 않는 한은 말이다.)

public class CounterPoint extends Point {
    private static final AtomicInteger counter = new AtomicInteger();
    
    public CounterPoint(int x, int y) {
        super(x, y);
        counter.incrementAndGet();
    }
    
    public static int numberCreated() { return counter.get(); }
}

// CounterPoint를 사용하는 테스트 프로그램
public class CounterPointTest {
    // 단위 원 안에 모든 점을 포함하도록 unitCircle을 초기화한다.
    private static final Set<Point> unitCircle = Set.of(
            new Point(1, 0), new Point(0, 1),
            new Point(-1, 0), new Point(0, -1));
    
    public static boolean onUnitCircle(Point p) {
        return unitCircle.contains(p);
    }
}

Point p1 = new Point(1, 0);
Point p2 = new CounterPoint(1, 0);

System.out.println(onUnitCircle(p1)); // true
System.out.println(onUnitCircle(p2)); // false (리스코프치환원칙을 만족한다면 true가 나와야한다.)

 

해결책 

  이에 대한 해결책으로 컴포지션을 권장하고 있다. 상속을 받아서 필드를 추가하고 싶은 경우에는 상속 대신 컴포지션을 사용해서 필드를 추가하도록 하자. 

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);
    }
}

Point p1 = new Point(1, 0);
Point p2 = new ColorPoint(1, 0, Color.RED).asPoint(); // asPoint 사용법
// Point p2 = new ColorPoint(1, 0, Color.RED); // 이렇게는 안된다.

 

  추이성에 대한 내용이 길었는데, 간단히 정리하면 아래와 같다.

• [생각의 흐름 1] 기존 방법 사용 - 대칭성 X
• [생각의 흐름 2] 타입까지 고려하여 만든 equals 사용 - 대칭성 O, 추이성 X
• [생각의 흐름 3] 각각의 타입까지 고려하여 만든 equals 사용 - 대칭성 O, 추이성 O, 리스코프 치환 원칙 X
• [해결책] 컴포지션을 활용하여 사용하자

 

4. 일관성(consistency)

  A.equals(B) == A.equals(B)

  일관성은 두 객체가 같다면(어느 하나 혹은 두 객체 모두가 수정되지 않는 한) 앞으로도 영원히 같아야 한다는 뜻이다. 가변 객체는 비교 시점에 따라 서로 다를 수도 혹은 같을 수도 있는 반면, 불변 객체는 한번 다르면 끝까지 달라야 한다.

  또한, 클래스가 불변이든 가변이든 equals의 판단에 신뢰할 수 없는 자원이 끼어들게 해서는 안 된다. (너무 복잡하게 구현하면 안 된다.) 최종적으로 어떤 것을 가리키냐로 비교하면 복잡한 것이다. 아래는 최종적인 IP를 비교하여 복잡하게 구현한 예시이다.

URL google1 = new URL("https", "about.google", "/products/");
URL google2 = new URL("https", "about.google", "/products/");
System.out.println(google1.equals(google2)); // true일 수도 있고, false일 수도 있다.

 

5. null-아님

  이것은 모든 객체가 null과 같지 않아야 한다는 뜻이다. 입력이 null이면 타입 확인 단계에서 false를 반환하기 때문에 null 검사를 명시적으로 하지 않아도 된다.

 

 

  이상으로 equals 메서드를 재정의할 때 반드시 지켜야 하는 일반 규약 5가지를 자세히 알아보았다.

 

해당 글은 백기선 님의 '이펙티브 자바 완벽 공략'을 수강하고 작성한 것입니다.