[이펙티브 자바] Item10. equals는 일반 규약을 지켜 재정의하라. (equals 구현 방법과 주의사항)

item10. equals는 일반 규약을 지켜 재정의하라. 

[이펙티브 자바] Item10. equals는 일반 규약을 지켜 재정의하라. (대칭성, 반사성, 추이성) (tistory.com)

[이펙티브 자바] Item10. equals는 일반 규약을 지켜 재정의하라. (대칭성, 반사성, 추이성)

 

[이펙티브 자바] Item10. equals는 일반 규약을 지켜 재정의하라. (추이성, 일관성, null-아님) (tistory.com)

[이펙티브 자바] Item10. equals는 일반 규약을 지켜 재정의하라. (추이성, 일관성, null-아님)

 

앞에서 equals 일반 규약에 대해서 학습했고, equals 메서드 구현 방법을 단계별로 정리한다. 

 

 

equals 구현방법

 

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

if (this == obj) {
   return true;
}

자기 자신이면 true를 반환한다. 

-> 이는 단순한 성능 최적화용으로, 비교 작업이 복잡한 상황일 때 값어치를 할 것이다. 

 

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

if (!(obj instanceof Point)) {
   return false;
}

-> 올바른 타입이 아니라면 false를 반환한다. 

 

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

Point p = (Point) obj;

-> 2단계에서 instanceof 검사를 했기 때문에 성공한다. 

 

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

return p.x == x && p.y == y;

모든 필드들이 일치하면 true를, 하나라도 다르면 false를 반환한다. 

이때 float와 double을 제외한 기본 타입 필드는 ==연산자로 비교하고, 참조 타입 필드는 각각 equals 메서드로, float와 double 필드는 각각 정적 메서드인 Float.compare(float, float)와 Double.compare(double, double) 로 비교한다. float와 double은 부동 소수값을 다뤄야 하기 때문이다. 

그리고 때론 null 도 정상 값으로 취급하는 참조  타입 필드도 있는데 이런 필드는 정적 메서드인 Objects.equals(Object, Object)로 비교해서 NPE를 예방하면 된다. 

 

그리고 어떤 필드를 먼저 비교하느냐가 equals의 성능을 좌우하기도 한다. 

최상의 성능을 바란다면 다를 가능성이 더 크거나 비교하는 비용이 싼 필드를 먼저 비교하면 좋다. 

 

 

🤗 equals 메서드 구현 방법 정리 

equals를 직접 작성할 수도 있지만 equals 작성을 도와주는 여러가지 방법들이 있다. 

 

- 구글의 AutoValue 

우선 build.gradle에 

compileOnly             "com.google.auto.value:auto-value-annotations:1.6"
annotationProcessor "com.google.auto.value:auto-value:1.6"

를 추가하고 gradle 한번 refresh 해준다. 

 

@AutoValue
abstract class Point
{
   static Point create(int x, int y)
   {
      return new AutoValue_Point(x, y); //  IDE에서는 없다고 하지만 컴파일 할 때 만들어준다.
   }
   
   abstract int x();
   
   abstract int y();

}

그리고 AutoValue_Point가 IDE에서는 없다고 컴파일 에러가 뜰 것이지만 컴파일 시점에 AutoValue_Point를 만들어준다!! (즉, 에러 아니란 소리) 

//
// Source code recreated from a .class file by IntelliJ IDEA
// (powered by FernFlower decompiler)
//

package chapter01.item10.autovalue;

final class AutoValue_Point extends Point {
    private final int x;
    private final int y;

    AutoValue_Point(int x, int y) {
        this.x = x;
        this.y = y;
    }

    int x() {
        return this.x;
    }

    int y() {
        return this.y;
    }

    public String toString() {
        return "Point{x=" + this.x + ", y=" + this.y + "}";
    }

    public boolean equals(Object o) {
        if (o == this) {
            return true;
        } else if (!(o instanceof Point)) {
            return false;
        } else {
            Point that = (Point)o;
            return this.x == that.x() && this.y == that.y();
        }
    }

    public int hashCode() {
        int h$ = 1;
        h$ *= 1000003;
        h$ ^= this.x;
        h$ *= 1000003;
        h$ ^= this.y;
        return h$;
    }
}

-> build -> classes 로 가보면 AutoValue_Point가 생성된 것을 확인할 수 있다. 

근데 이 구글의 AutoValue는 침투적이기도 해서 이 강의의 강사님은 잘 사용하지 않는다고 했다. 

 

 

- Lombok

대부분 이 Lombok을 사용하지 않을까 싶다. 

@EqualsAndHashCode
@ToString
public class Point
{
   private final int x;
   
   private final int y;
   
   public Point(int x, int y)
   {
      this.x = x;
      this.y = y;
   }
}

롬복을 사용하면 코드도 줄고 좋다. (약간의 논란? 이 있기는 하지만.. 사용에 무리는 없다고 한다.) 

 

 

- IDE 의 코드 생성 기능 사용 

이런식으로 인텔리제이에서는 equals와 hascode 생성을 도와준다. 

public class Point
{
   private final int x;
   
   private final int y;
   
   public Point(int x, int y)
   {
      this.x = x;
      this.y = y;
   }
   
   // IDE 사용 -> 단점: 코드가 지저분해진다, 필드가 늘어나면 다시 만들어야 한다.
   @Override
   public boolean equals(Object o)
   {
      if (this == o)
         return true;
      if (o == null || getClass() != o.getClass())
         return false;
      Point point = (Point) o;
      return x == point.x && y == point.y;
   }
   
   @Override
   public int hashCode()
   {
      return Objects.hash(x, y);
   }
}

-> 여기서 단점은 코드가 지저분해진다는 점과  필드가 추가되면 다시 만들어줘야 한다는 점이 있다!! (필드는 추가하고 equals 와 hascode를 수정하지 않으면 큰일난다 ㅎㅎ )

 

 

equals 주의사항 

 

1️⃣ equals를 재정의할 땐 hashcode도 반드시 재정의해야한다. 

 

2️⃣ 너무 복잡하게 해결하려 들지 말자!

필드들의 동치성만 검사해도 equals 규약을 어렵지 않게 지킬 수 있다. 오히려 너무 공격적으로 파고들다가 문제를 일으킬 수 있다. 

 

3️⃣ Object 외의 타입을 매개변수로 받는 equals 메서드는 선언하지 말자. 

 

public boolean equals(Point obj)
{
	...
}

이런식으로 입력타입을 Object가 아닌 다른 타입을 매개변수로 받으면 안된다..!! 

이건 오버라이딩이 아니라 오버로딩이 된다...