728x90
728x90
equals를 재정의한 클래스 모두에서 hashCode도 재정의해야 한다. 그렇지 않으면 hashCode 일반 규약을 어기게 되어 해당 클래스의 인스턴스를 HashMap이나 HashSet 같은 컬렉션의 원소로 사용할 때 문제를 일으킬 것이다. 아래는 Object 명세서에서 발췌한 것이다. equals 비교에 사용되는 정보가 변경되지 않는다면, 애플리케이션이 실행되는 동안 그 객체의 hashCode 메서드는 몇 번을 호출해도 일관되게 항상 같은 값을 반환해야 한다. 단, 애플리케이션을 다시 실행한다면 이 값이 달라져도 상관없다. equals(Object)가 두 객체를 같다고 판단했다면, 두 객체의 hashCode는 똑같은 값을 반환해야 한다. equals(Object)가 두 객체를 다르다고 판단했더라도, ..
equals 메서드는 재정의하기 쉬워 보이지만 곳곳에 함정이 도사리고 있다. 문제를 회피하는 가장 쉬운 방법은 아예 재정의하지 않는 것이다. 그냐 두면 그 클래스의 인스턴스는 오직 자기 자신과만 같게 된다. 그러니 아래와 같은 상황 중 하나에 해당한다면 재정의하지 않는 것이 최선이다. 각 인스턴스가 본질적으로 고유하다. 값을 표현하는 게 아니라 동작하는 개체를 표현하는 클래스가 여기 해당한다. Thread가 좋은 예로, Object의 equals 메서드는 이러한 클래스에 딱 맞게 구현되었다. 인스턴스의 '논리적 동치성(logical equlity)'을 검사할 일이 없다. 예컨대 java.util.regex.Pattern은 equals를 재정의해서 두 Pattern의 인스턴스가 같은 정규표현식을 나타내는지..
Equals와Hashcode, toString 등.. 기존의 정의되어있는 메소드를 오버라이딩을 하여 사용하는 경우가 많다. Equals와 toString은 어떤 용도로 사용하는지 알고있었지만, Hashcode의 경우 IntelliJ IDE의 자동완성 기능에서 종종 보았지만, 의미와 용도를 잘 모르고 지나치는 경우가 많았다. (부끄럽지만 알아볼 생각도 안했다) Equals와 Hashcode 메소드에 대해 알아보자 ! 아래의 코드와 같이 member1객체와 member2객체를 선언하고 객체를 비교하였을 때, 결과는 어떻게 될까? 답은 당연히 false일 것이다. 그 이유는 둘은 동일 객체가 아니기 때문이다. public class Test { public static void main(String[] arg..