백엔드 개발자 블로그

자바에서는 클래스를 복제해도 되는 것을 명시하는 용도인 Cloneable 인터페이스를 제공하고 있습니다. Cloneable 인터페이스를 구현하여 clone()메서드를 재정의한다면 객체의 필드들을 하나씩 복사하여 객체를 반환할 수 있습니다. 하지만 이러한 clone메서드는 Cloneable이 아닌 Object에 선언되어 있어 해당 객체가 clone()을 제공한다는 보장이 없다는 단점이 있습니다. clone() 메서드의 일반 규약 객체의 복사본을 만들어서 반환한다. 그리고 다음을 따른다. x.clone() != x 의 조건은 참이어야 한다, x.clone().getClass() == x.getClass() 위의 조건은 참이겠지만 반드시 그래야 하는 것은 아니다. x.clone().equals(x) 위의 코드..

toString 재정의 해야하는 이유 Object의 기본 toString메서드는 기본적으로 클래스 이름@16진수로 표현한 해시코드를 반환합니다. 실제로 Object.java파일의 toString메서드를 보면 다음과 같습니다. public String toString() { return getClass().getName() + "@" + Integer.toHexString(hashCode()); } 실제로 Car를 출력하였을 때 Car@6b71769e라는 결과가 나온 것을 확인할 수 있습니다. public class Car { private String name; private int position; } public class Main { public static void main(String[] arg..

equals를 재정의시 hashCode도 재정의 해야하는 이유 Ojbect 명세서에는 다음과 같은 규약이 있습니다. eauals 비교에 사용되는 정보가 변경되지 않는다면, 애플리케이션이 실행되는 동안 그 객체의 hashCode 메서드는 몇 번을 호출해도 일관되게 항상 같은 값을 반환해야 한다. 단, 애플리케이션을 다시 실행한다면 이 값이 달라져도 상관없다. equals(Object)가 두 객체를 같다고 판단했다면, 두 객체의 hashCode는 똑같은 값을 반환해야 한다. equals(Object)가 두 객체를 다르다고 판단했더라도, 두 객체의 hashCode가 서로 다른 값을 반환할 필요는 없다. 단, 다른 객체에 대해서는 다른 값을 반환해야 해시테이블의 성능이 좋아진다. 여기서 두번째에 위치한 조항을 ..