[이펙티브 자바] 아이템12 | toString을 항상 재정의하라

제롬·2022년 1월 20일
0

이펙티브자바

목록 보기
12/25

toString을 항상 재정의하라

  • Object의 기본 toString 메서드는 단순히 클래스_이름@16진수로_표현한_해시코드를 반환할 뿐이다.
    (toString의 일반 규약에 따르면 toString메서드는 "간결하면서 사람이 읽기 쉬운 형태의 유익한 정보" 를 반환해야 한다.)

  • 결정적으로 toString규약은 "모든 하위 클래스에서 이 메서드를 재정의하라"고 한다.
    (toString을 잘 구현한 클래스는 사용하기 편하고 그 시스템은 디버깅하기가 쉬워진다.)

toString 재정의 방법

  • toString은 그 객체가 가진 주요 정보 모두를 반환하는게 좋다.
    (만약 객체가 거대하거나 객체의 상태가 문자열로 표현하기에 적합하지 않다면 스스로를 완벽히 설명하는 요약정보를 담아야한다.)

  • toString을 구현할 때 반환값의 포맷을 문서화할지 정해야 한다.

    • 포맷을 명시하면 객체는 표준적이고 명확하고 사람이 읽기 좋다.
    • 만약 포맷을 명시한다면, 포맷에 맞는 문자열과 객체를 상호전환할 수 있는 정적 팩터리나 생성자를 함께 제공해주는것이 좋다.
    • 포맷을 명시하던 아니던 의도는 명확히 밝혀야 한다. (포맷을 명시하려면 아주 정확해야 한다.)
    • 포맷 명시 여부와 상관없이 toString이 반환한 값에 포함된 정보를 얻어올 수 있는 API를 제공하자.
      (예컨대, 아래의 경우 클래스에서 areaCode, prefix, lineNum을 제공해야 한다.)

[포맷을 명시할 경우]

    /** 이 전화번호의 문자열 표현을 반환한다.
     *  이 문자열은 "XXX-YYY-ZZZZ" 형태의 12글자로 구성된다.
     *  XXX는 지역 코드, YYY는 프리픽스, ZZZZ는 가입자 번호다.
     *  각각의 대문자는 10진수 하나를 나타낸다.
     *  전화번호의 각 부분의 값이 너무 작아서 자릿수를 채울 수 없다면,
     *  앞에서부터 0으로 채워나간다. 예컨대 가입자 번호가 123이라면
     *  전화번호의 마지막 네 문자는 "0123"이 된다. 
     */

    @Override
    public String toString() {
        return String.format("%03d-%03d-%04d", areaCode, prefix, lineNum);
    }

[포맷을 명시하지 않을 경우]

/** 
* 이 약물에 관한 대략적인 설명을 반환한다. 
* 다음은 이 설명의 일반적인 형태이나, 
* 상세 형식은 정해지지 않았으며 향후 변경될 수 있다. 
* 전화번호의 각 부분의 값이 너무 작아서 자릿수를 채울 수 없다면, 
* 앞에서부터 0으로 채워나간다. 예컨대 가입자 번호가 123이라면 
*/ 

@Override 
public String toString() { 
	.... 
}

이렇게 의도를 밝혀두면 이 포맷을 사용한 프로그래머는 포맷이 바뀌어 피해를 입어도 자신을 탓할 수 밖에 없다.

toString 재정의 장점

toString을 잘 구현한 클래스는 디버깅하기 쉽다.

간결하면서 사람이 읽기 쉬운 형태의 유익한 정보를 반환하기 때문이다.

[읽기 쉬운 형태의 정보를 반환하는 toString 메서드]

PhoneNumber jenny = new PhoneNumber(707, 867, 5309);
System.out.println("jenny=" + jenny);

toString을 제대로 재정의했다면 메시지만으로 문제를 진단하기 충분하다. 예컨대, {jenny=PhoneNumber@adbbd} 같은 메시지보다 {jenny=707-867-5309}메시지가 훨씬 유용하다.

toString 재정의 단점

포맷을 한번 명시하면 평생 그 포맷에 얽히게 된다.

해당 포맷에 맞춰 다른 프로그래머들이 파싱하고 새로운 객체를 만들고 영속 데이터로 저장하는 코드를 작성할 것이다. 만약 향후 릴리스에서 포맷을 바꾼다면 이를 사용하던 코드들과 데이터들이 엉망이 될것이다.

반대로 포맷을 명시하지 않는다면 향후 릴리스에서 정보를 더 넣거나 포맷을 개선할 수 있는 유연성을 얻게된다.

toString 재정의가 불필요한 경우

  • 정적 유틸리티 클래스
  • 열거 타입 (자바에서 이미 완벽한 toString 제공)
  • 컬렉션 구현체
    • 컬렉션 구현체는 추상 컬렉션 클래스들의 toString을 상속받아 쓴다.
    • 주의할 점은 하위 클래스들이 공유해야 할 문자열 표현이 있는 추상 클래스라면 toString을 재정의 해주어야 한다는 점이다.

[결론]

모든 구체 클래스에서 ObjecttoString을 재정의하자. 상위 클래스에서 이미 알맞게 재정의한 경우는 예외다. toString은 해당 객체에 관한 명확하고 유용한 정보를 읽기 좋은 형태로 반환해야 한다.

0개의 댓글