Home [Effective Java] Item12. toString을 항상 재정의하라!
Post
Cancel

[Effective Java] Item12. toString을 항상 재정의하라!

Item12. toString을 항상 재정의하라!

  • Object의 기본 toString 메서드는 우리가 작성한 클래스에 적합한 문자열을 반환하는 경우는 거의 없다.
  • 기본 toString 메서드는 클래스_이름@16진수해시코드를 반환할 뿐이다.
  • toString 메서드의 일반 규약에 따르면 간결하면서 읽기 쉬운 형태의 유익한 정보를 반환해야 한다.
  • 고로 좋은 사용성과 디버깅의 편의를 위해 재정의가 필요하다.

toString의 호출

  • toString 메서드는 객체를 println, printf, 문자열 연결 연산자(+), assert 구문에 넘길 때, 혹은 디버거가 객체를 출력할 때 자동으로 불린다.

  • 즉, 직접적인 호출을 하지 않더라도 다른 어딘가에서는 쓰인다는 이야기다.
  • toString을 제대로 재정의하지 않는다면 로그에도 쓸모없는 메시지만 남을 수도 있다는 이야기다.
  • 실전에서 toString 호출 시 그 객체가 가진 주요 정보 모두를 반환하는 것이 좋다.
  • 객체가 거대하거나 객체의 상태가 문자열로 표현하기에 적합하지 않다면 객체가 가진 정보를 모두 반환하는 데에는 무리가 있으니 요약 정보를 담아 반환하는 방향으로 간다.

toString의 문서화

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

  • 전화번호나 행렬 같은 값 클래스라면 문서화하기를 권한다.

  • 포맷을 명시하면 그 객체는 표준적이고, 명확하고, 사람이 읽을 수 있게 된다.

    • 값을 바로 입출력에 사용, csv 파일과 같이 데이터 객체 파일로의 변환도 손쉽게 가능해진다.
    • 명시한 포맷에 맞는 문자열과 객체를 상호 전환할 수 있는 정적 팩터리나 생성자를 함께 제공하는 것이 좋다.
    • 단점으로는, 포맷 명시 시 평생 그 포맷에 얽매이게 된다는 것이다. (사용자들이 이미 그 포맷에 맞는 파싱, 객체, 데이터를 사용 중이므로 수정 어려움)
  • 포맷을 명시하든 아니든 의도는 명확히 밝히자.

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    
    /**
    * 이 전화번호의 문자열 표현을 반환한다.
    * 이 문자열은 "XXX-YYY-ZZZZ" 형태의 12글자로 구성된다.
    * XXX는 지역 코드, YYY는 프리픽스, ZZZZ는 가입자 번호다.
    * 각각의 대문자는 10진수 숫자 하나를 나타낸다.
    *
    * 전화번호의 각 부분의 값이 너무 작아서 자릿수를 채울 수 없다면,
    * 앞에서부터 0으로 채워나간다. 예컨대 가입자 번호가 123이라면
    * 전화번호의 마짐가 네 문자는 "0123"이 된다.
    */
    @Override
    public String toString() {
    	return String.format("%3d-%03d-%04d", areaCode, prefix, lineNum);
    }
      
    /*
    * 이 약물에 관한 대략적인 설명을 반환한다.
    * 다음은 이 설명의 일반적인 형태이나,
    * 상세 형식은 정해지지 않았으며 향후 변경될 수 있다.
    *
    * "[약물 #9: 유형=사랑, 냄새=테레빈유, 겉모습=먹물]"
    */
    @Override
    public String toString() { ... }
    
    • 아래 방식처럼 포맷 명시를 하지 않는다면, 사용자가 포맷이 변경되어 피해를 입어도 책임을 물을 수는 없을 것이다.
  • 포맷 명시 여부와 상관 없이 toString이 반환한 값에 포함된 정보를 얻어올 수 있는 API를 제공하자.

    • 제공하지 않는다면 사용자는 정보를 얻기 위해 일일히 toString 반환값을 파싱해 사용해야 하니 성능이 나빠지고, 필요치 않은 작업이 늘어난다.
    • 또 향후 포맷 변경 시, 파싱해서 사용하던 시스템이 망기지는 결과를 초래할 수 있다.
    • 정보를 얻어올 수 있는 접근자를 제공하지 않으면 사실상 toString 포맷이 준-표준 API나 다름없어짐을 유의하자.

toString 재정의가 필요없는 경우

  • 정적 유틸리티 클래스는 toString을 제공할 이유가 없다.
  • 대부분의 열거 타입도 자바가 이미 완벽한 toString 메서드를 제공한다.
  • 하위 클래스들이 공유해야 할 문자열 표현이 있는 추상 클래스라면 toString을 재정의해줘야 한다.

핵심 정리

  • 모든 구체 클래스에서 Object의 toString을 재정의하자. 상위 클래스에서 이미 알맞게 재정의한 경우는 예외이다.
  • toString을 재정의한 클래스는 높은 사용성, 시스템 디버깅의 편의성을 선사한다.
  • toString은 해당 객체에 관한 명확하고 유용한 정보를 읽기 좋은 형태로 반환해야 한다.
This post is licensed under younghwani by the author.

[Effective Java] Item11. equals를 재정의하려거든 hashCode도 재정의하라!

[Effective Java] Item13. clone 재정의는 주의해서 진행하라!

Comments powered by Disqus.