Object의 기본 toString 메서드가 작성한 클래스의 적합한 문자열을 반환하는 경우는 거의 없다.
이 메서드는 단순히 클래스_이름@16진수로_표시한_해시코드 를 반환할 뿐이다.
toString의 일반 규약에 따르면 '간결하면서 사람이 읽기 쉬운 형태의 유익한 정보'를 반환해야 한다.
또한, toString의 규약은 '모든 하위 클래스에서 이 메서드를 재정의하라'고 한다.
equals와 hashCode 규약만큼 대단히 중요하진 않지만, toString 을 잘 구현한 클래스는 사용하기 훨씬 즐겁고, 디버깅하기 쉽다.
그렇다면 이제부터
toString을 재정의할 때 유의할 점을 알아보자.
✔️ 실전에서 toString은 그 객체가 가진 주요 정보 모두를 반환하는 게 좋다.
만약 객체가 거대하거나, 객체의 상태가 문자열로 표현하기에 적합하지 않다면 요약 정보를 담아야 한다.
이상적으로는 스스로를 완벽히 설명하는 문자열이어야 한다.
다음은 주요 정보가 담기지 않았을 때 문제가 되는 대표적은 예이다.
Assertion failure: expected {abc, 123}, but was {abc, 123}.
✔️ toString 을 구현할 때면 반환값의 포맷을 문서화할지 정해야 한다.
전화번호나 행렬 같은 값 클래스라면 문서화하기를 권한다. 포맷을 명시하면 그 값 그대로 입출력에 사용하거나 CSV 파일처럼 사람이 읽을 수 있는 데이터 객체로 저장할 수도 있다. 포맷을 명시하기로 했다면, 명시한 포맷에 맞는 문자열과 객체를 상호 전환할 수 있는 정적 팩터리나 생성자를 함께 제공해주면 좋다.
단점은 포맷을 한번 명시하면, 평생 그 포맷에 얽매이게 된다는 점이다.
만약 향후 릴리스에서 포맷을 바꾼다면 이를 사용하던 코드들과 데이터들은 엉망이 될 것이고 프로그래머들은 절규할 것이다.
반대로 포맷을 명시하지 않는다면 향후 릴리스에서 정보를 더 넣거나 포맷을 개선할 수 있는 유연성을 얻게 된다.
✔️ 포맷을 명시하든 아니든 의도는 명확히 밝혀야 한다.
포맷을 명시하려면 아주 정확하게 해야 한다. 다음 PhoneNumber 클래스에 대한 예제를 보자.
/**
* 이 전화번호의 문자열 표현을 반환한다.
* 이 문자열은 '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를 제공하자.
예컨대 PhoneNumber 클래스는 지역 코드, 프리픽스, 가입자 번호용 접근자를 제공해야 한다.
그렇지 않으면 이 정보를 필요한 프로그래머는 toString의 반환값을 파싱할 수 밖에 없다.
이러한 파싱 작업은 성능을 나빠지게 하고, 필요하지도 않은 작업이다.
게다가 향후 포맷을 바꾸면 시스템이 망가지는 결과를 초래할 수 있다.
접근자를 제공하지 않으면 변경될 수 있다고 문서화했더라도 그 포맷이 사실상 준-표준 API나 다름없어진다.
✔️ toString 메서드를 재정의하지 않아도 되는 경우
정적 유틸리티 클래스의 경우, toString 을 제공할 이유가 없다.열거 타입은 자바가 이미 완벽한 toString을 제공하기 때문에 재정의하지 않아도 된다.
그러나 하위 클래스들이 공유해야 할 문자열 표현이 있는 추상 클래스라면 toString을 재정의해야 한다.
💡 AutoValue 프레임워크
AutoValue 프레임워크는toString도 자동으로 생성해준다.
이것은 각 필드의 내용을 멋지게 나타내 주기는 하지만 클래스의 '의미'까지는 파악하지 못한다.
비록 자동 생성에 적합하지는 않더라도 객체의 값에 관해 아무것도 알려주지 않는 Object의 toString보다는 자동 생성된 toString이 훨씬 유용하다.
📌 핵심 정리
모든 구체 클래스에서 Object의 toString을 재정의하자.
상위 클래스에서 이미 알맞게 재정의한 경우는 예외다.
toString을 재정의한 클래스는 사용하기도 즐겁고 그 클래스를 사용한 시스템을 디버깅하기 쉽게 해준다.
toString은 해당 객체에 관한 명확하고 유용한 정보를 읽기 좋은 형태로 반환해야 한다.
