아이템 12. toString을 항상 재정의하라. - ksw6169/effective-java GitHub Wiki

toString을 재정의해야 하는 이유

Object의 toString 메소드는 객체를 println, printf, 문자열 연결 연산자(+), assert 구문에 넘기거나 디버거가 객체를 출력할 때 자동으로 호출되는데, toString을 제대로 정의하지 않는다면 쓸모없는 메시지만 로그에 남는다.

// Object.toString을 그대로 사용한 예(클래스명@16진수로_표시한_해시코드 를 반환한다.)
PhoneNumber@adbbd

toString을 제대로 재정의하면 그 클래스를 사용할 때 디버깅하기가 쉬워진다.

// toString을 제대로 정의한 클래스는 다음 코드만으로 문제를 진단하기에 충분한 메시지를 남길 수 있다.
System.out.println(phoneNumber + "에 연결할 수 없습니다.");

toString의 일반 규약

간결하면서 사람이 읽기 쉬운 형태의 유익한 정보를 반환해야 한다.
모든 하위 클래스에서 이 메소드를 재정의하라.

toString을 구현할 때 유의사항

1. 객체가 가진 주요 정보 모두를 반환하는 것이 좋다.

만약 객체가 거대하거나 객체의 상태가 문자열로 표현하기에 적합하지 않다면 요약 정보를 담아주면 된다. 다음의 테스트 실패 메시지는 toString에 주요 정보가 담기지 않았을 때 문제가 되는 대표적인 예다.

Assertion failure: expected {abc, 123}, but was {abc, 123}.
// 단언 실패: 예상값 {abs, 123}, 실제값 {abc, 123}.

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

전화번호나 행렬 같은 값 클래스라면 문서화하기를 권한다. 포맷을 명시하면 그 객체는 표준적이고, 명확하고, 사람이 읽을 수 있게 된다. 따라서 그 값 그대로 입출력에 사용하거나 CSV 파일처럼 사람이 읽을 수 있는 데이터 객체로 저장할 수도 있다.

포맷을 명시한다면 포맷에 맞는 문자열과 객체를 상호 전환할 수 있는 정적 팩토리, 생성자를 함께 제공해주면 좋다. 이 방식은 자바 플랫폼의 많은 값 클래스가 따르는 방식이다. BigInteger, BigDecimal과 대부분의 기본 타입 클래스가 여기에 해당된다.

toString의 포맷을 정의할 때는 단점이 있는데 포맷을 한번 명시하면 평생 그 포맷에 얽매이게 된다. 이를 사용하는 프로그래머들이 그 포맷에 맞춰 사용할 것이기 때문이다. 이 포맷을 향후 릴리즈에서 바꾼다면 이를 사용하던 코드들과 데이터들은 엉망이 될 것임은 자명한 사실이다.

포맷을 명시하든 아니든 toString이 수행하고자 하는 의도는 명확히 밝혀야 한다.

/**
 * 이 전화번호의 문자열 표현을 반환한다.
 * 이 문자열은 "XXX-YYY-ZZZZ" 형태의 12자로 구성된다.
 * XXX는 지역 코드, YYY는 프리픽스, ZZZZ는 가입자 번호다.
 * 각각의 대문자는 10진수 숫자 하나를 나타낸다.
 *
 * 전화번호의 각 부분의 값이 너무 작아서 자릿수를 채울 수 없다면,
 * 앞에서부터 0으로 채워나간다. 예컨대 가입자 번호가 123이라면
 * 전화번호의 마지막 네 문자는 "0123"이 된다.
 */
@Override
public String toString() {
    return String.format("%03d-%03d-%04d", areaCode, prefix, lineNum);
}

포맷을 명시하지 않기로 했다면 다음처럼 작성할 수 있다. 이러한 설명을 읽고도 이 포맷에 맞춰 코딩하거나 특정 값을 빼내어 영구 저장한 프로그래머는 나중에 포맷이 바뀌어 피해를 입어도 자기 자신을 탓할 수 밖에 없다.

/**
 * 이 약물에 관한 대략적인 설명을 반환한다.
 * 다음은 이 설명의 일반적인 형태이나,
 * 상세 형식은 정해지지 않았으며 향후 변경될 수 있다.
 *
 * "[약물 #9: 유형=사랑, 냄새=테레반유, 겉모습=먹물]"
 */
@Override
public String toString() { ... }

3. 포맷 명시 여부와 상관없이 toString이 반환한 값에 포함된 정보를 얻어올 수 있는 API를 제공하자.

예컨대 PhoneNumber 클래스는 areaCode, prefix, lineNum 용 접근자를 제공해야 한다. 그렇지 않으면 이 정보가 필요한 프로그래머는 toString의 반환값을 파싱할 수 밖에 없다.

4. 정적 유틸리티 클래스, 열거 타입은 toString을 제공하지 않아도 된다.

여기서 열거 타입은 자바가 이미 완벽한 toString을 제공하니 따로 재정의하지 않아도 된다. 하지만 하위 클래스들이 공유해야 할 문자열 표현이 있는 추상 클래스라면 toString을 재정의해줘야 한다. 예컨대 대다수의 컬렉션 구현체는 추상 컬렉션 클래스들의 toString 메소드를 상속해 쓴다.

5. toString 생성 시 AutoValue 프레임워크를 사용할 수 있다.

AutoValue는 toString을 자동 생성해주지만 클래스의 의미까지 파악하지는 못하므로 PhoneNumber와 같은 클래스에서는 부적합하다. 하지만 Object의 toString을 그냥 쓰는 것보다는 AutoValue를 통해 자동 생성된 toString이 훨씬 유용하다.

참고 자료

Effective Java 3/E