====== Java equals & hashCode ====== * [[java:equals_verifier|Equals Verifier]] ''equals'', ''hashCode'' 테스트 자동화 * [[java:hibernate:equalsandhashcode|Hibernate and equals & hashCode]] ===== 자주하는 equals & hashCode 실수 및 올바른 구현 ===== * [[https://www.artima.com/lejava/articles/equality.html|How to Write an Equality Method in Java]] ==== 잘못된 ''equals'' 메소드 시그너쳐 ==== public boolean equals(ClassName other) { // 잘못된 equals!! } // 다음이 올바르다. 무조건 다음과 같이한다. public boolean equals(Object other) { ... } ==== equals가 변경되면 hashCode도 변경해야한다 ==== * ''equals''가 사용하는 필드와 ''hashCode''가 사용하는 필드를 동일하게 맞춰야 한다. * 그렇지 않으면 ''HashSet.contains'' 등이 올바르게 작동하지 않게 된다. HashSet은 hashCode 기반으로 bucket을 결정한다. * **hashCode 규약** * 두 개의 객체가 ''equals(Object)'' 호출시 ''true''라면 두 객체의 ''hashCode()''는 동일한 int 를 리턴해야 한다. * ''hashCode''는 ''equals''에서 사용한 필드들만을 사용해야한다. ==== Mutable(변경가능한) 필드에 대한 equals/hashCode 구현은 하면 안 된다 ==== * 변경가능한 필드에 대해 ''equals'', ''hashCode''를 구현한 상태에서 해당 필드 값을 변경하면 동일 객체라도 hashCode가 바뀌게 된다. * 이 상태로 필드 변경전에 HashSet에 값을 넣었다면, 필드 값을 변경한 후에는 해당 객체를 HashSet에서 찾을 수 없게 된다. hashCode로 bucket을 결정하는데 hashCode가 바뀌었기 때문이다. ==== 동치(equivalence)를 위반해서는 안된다 ==== ''equals''는 ''null''이 아닌 객체간에는 항상 동치 관계를 유지하게 구현해야만 한다. * 반사성(reflexive) : null이 아닌 x에 대해 ''x.equals(x)''는 항상 ''true''여야 한다. * 대칭성(symmetric) : null이 아닌 x, y에 대해, 오직 ''y.equals(x)''가 ''true''일 때만 ''x.equals(y)''도 ''true''여야 한다. [[https://github.com/kwon37xi/research-java8/blob/master/java-8-others/src/main/java/equality/no_equivalance_relation/NoSymmetricColoredPoint.java|대칭성 위반 예]] * 이행성(transitive) : null이 아닌 x,y,z에 대해, ''x.equals(y)''가 ''true''이고 ''y.equals(z)''가 ''true''이면 ''x.equals(z)''도 ''true''여야 한다. [[https://github.com/kwon37xi/research-java8/blob/master/java-8-others/src/main/java/equality/no_equivalance_relation/NoTransientColoredPoint.java|이행성 위반 예]] * 일관성(consistent) : null이 아닌 x, y에 대해, 객체의 동등성 비교에 사용된 정보에 변경이 없다면 ''x.equals(y)''를 여러번 호출해도 일관성있게 ''true''를 반환하거나 일관성있게 ''false''를 반환해야 한다. * null이 아닌 값 x 에 대해 ''x.equals(null)''은 항상 ''false''를 반환해야 한다. * [[https://github.com/kwon37xi/research-java8/blob/master/java-8-others/src/main/java/equality/no_equivalance_relation/WrongStrictPoint.java|상속관계에 지나치게 엄격 한 예]] 상속 관계에서는 위 동치성을 쉽게 위반하게 된다. ''canEqual'' 메소드를 통해 이를 지켜내야 한다. ==== 동치 문제의 최종 해결책 canEqual ==== ''equals''와 ''hashCode''를 override 할 때마다 ''can equal''메소드도 함께 구현하고 오버라이드 해주면 된다. 이를 통해 현재 클래스의 상위클래스와 동등하게 평가되는 것을 막을 수 있다. * [[https://github.com/kwon37xi/research-java8/blob/master/java-8-others/src/main/java/equality/Point.java|Point.java]] * [[https://github.com/kwon37xi/research-java8/blob/master/java-8-others/src/main/java/equality/ColoredPoint.java|ColoredPoint.java]] // Point 라는 클래스가 존재할 때 public boolean canEqual(Object other) { return (other instanceof Point); } @Override public boolean equals(Object other) { boolean result = false; if (other instanceof Point) { Point that = (Point) other; // that.canEqual(this) 가 핵심이다. 이를 거꾸로 this.canEqual(that) 으로 사용하면 안된다. result = (that.canEqual(this) && this.getX() == that.getX() && this.getY() == that.getY()); } return result; } // 오버라이드 되는 ColoredPoint 클래스에서는 @Override public boolean equals(Object other) { boolean result = false; if (other instanceof ColoredPoint) { ColoredPoint that = (ColoredPoint) other; result = (that.canEqual(this) && this.color.equals(that.color) && super.equals(that)); } return result; } // that.canEqual(this) 호출을 통해서 상위클래스(Point)는 결코 ColoredPoint와 같을 수 없게 보장됨. @Override public boolean canEqual(Object other) { return (other instanceof ColoredPoint); } * 프로그래머는 상위클래스에 ''canEqual''이 구현되어 있는 경우 하위 클래스에서 ''canEqual''을 구현하거나 하지 않음으로써 상위클래스와의 동등성 비교를 허용하거나 안할 수 있다. ===== 다른 타입간의 equals 탐지 ===== * 서로 다른 타입간의 equals는 항상 ''false''가 될 가능성이 높은 잘못된 코딩이다. * [[java:findbugs|Java FindBugs]]와 이를 사용하는 [[intellij_idea:qaplug|QAPlug]], [[java:sonarqube|SonarQube]] 등으로 탐지 가능하다. * [[http://findbugs.sourceforge.net/bugDescriptions.html#EC_UNRELATED_TYPES|EC: Call to equals() comparing different types (EC_UNRELATED_TYPES)]] 을 비롯한 ''EC'', ''EQ'' 계통을 살펴본다.