kingsubin

toString 규약

• 간결하면서 사람이 읽기 쉬운 형태의 유익한 정보를 나타내라
• 모든 하위 클래스에서 이 메서드를 재정의하라

Object.toString()

public String toString() {
    return getClass().getName() + "@" + Integer.toHexString(hashCode());
}

IDE에서의 toString() 재정의

// PhoneNumber.class
@Override
public String toString() {
    return "PhoneNumber{" +
                "areaCode= '" + areaCode + '\'' +
                ", prefix='" + prefix + '\'' +
                ", lineNum='" + lineNum + '\'' +
                '}';
}

왜 toString()을 재정의 하는가 ?

• 사용하기 훨씬 즐겁고, 디버깅 하기 쉽다.
• 직접 알려주는 형태가 훨씬 유익한 정보를 담고 있다.
• 기존 PhoneNumber 클래스 호출시 → PhoneNumber@adbbd
• 재정의시 → 707-867-5309

toString()가 호출될때

• println
• printf
• 문자열 연결 연산자 +
• assert 구문에 넘길때
• 디버거가 객체를 출력할 때

어떻게 재정의 하는가 ?

• 그 객체가 가진 주요 정보 모두를 반환하는게 좋다.
• 하지만 객체가 거대하거나 문자열로 표현하기 적합하지 않다면 무리가 있다.
• 이럴때는 "맨해튼 거주자 전화번호부(총 9412323개)" 과 같이 요약 정보를 담아야 한다.
• 이상적으로는 스스로를 완벽히 설명하는 문자열이어야 한다.

포맷을 문서화할지 말지 ?

• 반환값의 포맷을 문서화할지 정해야 한다.
• 전화번호나 행렬 같은 값 클래스라면 문서화 하기를 권한다.
• 포맷을 명시하게 된다면 그 객체는 표준적이고, 명확하고, 사람이 읽을 수 있게 된다.
• 포맷을 명시하든 아니든 의도는 명확히 밝혀야 한다.
• 명시하려면 ? 아주 정확하게 명시할 것.
• 명시하기로 정했다면, 명시한 포맷에 맞는 문자열과 객체를 상호 전환할 수 있는 정적 팩토리나 생성자를 함께 제공해주면 좋다.
• ex. BigInteger, BigDecimal

포맷 명시시의 단점

• 한번 명시하면 평생 그 포맷에 얽매이게 된다.
• 처음에 명시한대로 프로그래머들이 코드를 작성할 것인데 추후에 포맷을 바꾼다면 이를 사용하던 코드들과 데이터들은 엉망이 될 것이다.
• 반대로 포맷을 명시하지 않는다면 향후 릴리스에서 정보를 더 넣거나 포맷을 개선할 수 있는 유연성을 얻게 된다.

포맷 명시하는 경우

/**
* 이 전화번호의 문자열 표현을 반환한다.
* 이 문자열은 "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() { ... }

주의사항

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

팁

• 정적 유틸리티 클래스는 toString을 제공할 이유가 없다.
• 또한, 대부분의 열거 타입도 이미 완벽한 toString을 제공하니 따로 재정의하지 않아도 된다.
• 하지만 하위 클래스들이 공유해야 할 문자열 표현이 있는 추상 클래스라면 toString을 재정의해줘야 한다.
• 예를들어 Collection 구현체는 추상 컬레션 클래스의 toString 메서드를 상속해서 쓴다.
• 자동 생성에 적합하지는 않더라도 객체의 값에 관해 아무것도 알려주지 않는 Object의 toString보다는 자동 생성된 toString이 훨씬 유용하다.

결론

모든 구체 클래스에서 Object의 toString을 재정의하자. 상위 클래스에서 이미 알맞게 재정의한 경우는 예외다.

toString을 재정의한 클래스는 사용하기도 즐겁고 그 클래스를 사용한 시스템을 디버깅하기 쉽게 해준다.

toString은 해당 객체에 관한 명확하고 유용한 정보를 읽기 좋은 형태로 반환해야 한다.