본문 바로가기

Reading

(65)
[Effective-Java] Item 13. clone 재정의는 주의해서 진행하라 clone()을 정의하기 위해서는 Clonable 믹스인 인터페이스를 구현해야한다. 하지만 clone() 메소드가 선언된 곳은 믹스인 인터페이스인 Clonable이 아니라 Object이고, 그마저도 protected다. Clonable을 구현하는 것 만으로는 clone 메소드를 호출할 수 없고, 리플렉션을 사용하면 가능하겠지만 100% 성공도 아니다. Clonable 인터페이스는 Object의 protected 메소드인 clone 메소드의 동작 방식을 변경한다. 실제 Clonable 인터페이스는 비어있고, 선택적으로 clone()을 오버라이딩할 수 있게 준비되어있다.(아래 코드에 구현하라고 나온다) implements Clonable을 하고 clone()을 오버라이딩해서 사용하면 정상적으로 객체가 복사되..
[Effective-Java] Item 12. toString을 항상 재정의하라 Object의 기본 toString 메소드는 단순히 클래스_이름@16진수로_표시한_해시코드로 반환한다. ex) PhoneNumberB@adbbd toString에 대한 내용과 일반 규약 간결하면서 사람이 읽기 쉬운 형태의 유익한 정보를 반환 모든 하위 클래스에서 이 메소드를 재정의 equals와 hashCode 규약만큼 중요하진 않지만, 더 사용하기 좋고 디버깅이 쉽다. 어떻게 사용되고 사용해야 하나? toString은 직접 호출하지 않더라도 다른 어딘가에서 호출된다. 예를들어 println, printf, 문자열 연결 연산자(+), assert 구문에 넘길 때, 디버거가 객체를 출력할 때 등에서 말이다. 만약 재정의를 하지 않으면 제일 처음에 말했던 별로 쓸모 없는 메시지가 호출된다. 그리고 그 객체가..
[Effective-Java] Item 11. equals를 재정의하려거든 hashcode도 재정의하라 equals를 재정의한 클래스 모두에서 hashCode도 재정의해야 한다. 그렇지 않으면 hashCode 일반 규약을 어기게 되어 해당 클래스의 인스턴스를 HashMap, HashSet 같은 컬렉션의 원소를 사용할 때 문제가 생긴다. Object에서 발췌한 hashCode() 명세 규약 equals 비교에 사용되는 정보가 변경되지 않았다면 항상 같은 값을 반환해야 한다. equals(Object)가 두 객체를 같다고 판단했으면, 두 객체의 hashCode는 똑같은 값을 반환해야 한다. equals(Object)가 두 객체를 다르다고 판단했더라도, 두 객체의 hashCode가 서로 다른 값을 반환할 필요는 없다. 하지만 다른 값을 반환해야 성능이 유리하다 아래와 같은 클래스가 있다고 했을 때, public..
[Effective-Java] Item 10. equals는 일반 규약을 지켜 재정의하라 equals는 재정의하지 않으면 클래스의 인스턴스는 자기 자신과만 같게 된다. 따라서 필요한 경우에만 재정의해서 사용해야한다. equals를 재정의하지 않아도 될 때 1. 각 인스턴스가 본질적으로 고유할 때. 즉, 값이 아니라 동작하는 개체를 표현할 때. ex) Thread 2. 인스턴스의 '논리적 동치성(logical equality)'을 검사할 일이 없을 때 java.util.regex.Pattern은 equal를 재정의하여 두 Pattern의 인스턴스가 같은 정규표현식인지 검사한다. 하지만 설계자의 판단에 따라 기본 Object의 equals를 사용해도 된다. 3. 상위 클래스에서 재정의한 equals가 하위 클래스에도 들어맞을 때 ex) Set은 AbstractSet, List구현체들은 Abstr..