Object에서 재정의를 염두에 두고 설계된 메서드에 대해서 일반 규약이 정의되어 있음, 그래서 그 중 먼저 equals를 알아볼 것임 equals의 경우 재정의가 쉬워보이지만 고려할 부분이 꽤 있음, 이 문제를 회피하는 것은 재정의를 하지 않는 것이긴 함, 그렇게
equals를 재정의한 클래스 모두에서 hashCode도 재정의해야함그렇지 않으면 해당 클래스의 인스턴스를 HashMap이나 HashSet 같은 컬렉션의 원소로 사용할 때 문제를 일으킴hashCode 재정의를 잘못했을 때 크게 문제되는 사항은 논리적으로 같은 객체는 같
toString메서드가 우리가 작성한 클래스에 적합한 문자열을 반환하는 경우는 거의 없음, 단순히 클래스\_이름@16진수로\_표시한\_해시코드를 반환할 뿐임해당 메서드에 일반 규약은 간결하면서 사람이 읽기 쉬운 형태의 유익한 정보를 반환해야함, 모든 하위 클래스에서 이
cloneable은 복제해도 되는 클래스임을 명시하는 용도의 믹스인 인터페이스지만, 아쉽게도 의도하나 목적을 제대로 이루지 못했음 왜냐하면 clone 메서드가 선언된 곳이 Cloneable이 아닌 Object이고 그마저도 protected라는데 있음 그래서 Clon
Comparable 인터페이스의 유일한 메서드 compareTo는 Object 메서드가 아니며 단순 동치성 비교에 더해 순서까지 비교할 수 있으며 제네릭함Comparable을 구현했다는 것은 그 클래스의 인스턴스에는 자연적인 순서가 있음을 뜻함검색, 극단값 계산, 자동