[아이템 12] toString을 항상 재정의하라

toString의 재정의

Object의 기본 toString 메소드가 우리가 작성한 클래스에 적합한 문자열을 반환하는 경우는 거의 없다

 

Object의 기본 toString을 반환할시에는 일반적으로 클래스_이름@16진수로_표시한_해시코드를 반환한다.

toString의 일반 규약에 따르면 '간결하면서 사람이 읽기 쉬운 형태의 유익한 정보'를 반환해야 한다.

 

기본 제공하는 toString은 클래스 명 + 16진수의 해시코드 임으로 읽기 쉬운 형태가 아니다.

따라서 toString을 제대로 사용하기 위해서는 '모든 하위 클래스에서 이 메소드를 재정의'해야 한다.

---

toString으로 잘 구현한 클래스는 사용하기에 훨씬 즐겁고, 그 클래스를 사용한 시스템은 디버깅하기 쉽다.

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

직접 호출하지 않더라도 다른 어딘가에 쓰일 것이다.

 

좋은 toString은 이 인스턴스가 포함하는 객체에서 유용하게 쓰인다.

실전에서 toString은 그 객체가 가진 주요 정보 모두를 반환하는게 좋다.

---

포맷과 문서화

포맷의 문서화

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

👉🏻 아주 중요한 선택

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

 

포맷 문서화의 장점

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

따라서 그 값 그대로 입출력에 사용하거나 CSV 파일처럼 사람이 읽을 수 있는 데이터 객체로 저장할 수 있다.

포맷을 명시하기로 결정했다면, 명시한 포맷에 맞는 문자열과 객체를 상호 전환할 수 있는 정적 팩토리나 생성자를 함께 제공해주면 좋다.

 

포맷 문서화의 단점

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

향후 릴리즈에서 포맷을 바꾼다면 기존 포맷을 사용하던 코드들과 데이터들은 엉망이 된다.

👉🏻오히려 포맷을 명시하지 않는 경우 릴리스에서 정보를 더 넣거나 포맷을 개선할 수 있는 유연성을 얻게 된다.

 

어쨌거나....

포맷을 명시하든 아니든 프로그래머의 의도는 명확히 밝혀야 한다.

또한, 포맷을 명시하려면 아주 정확하게 해야 한다.

 

예제

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

 

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

API를 제공하지 않는다면, 정보가 필요한 프로그래머는 toString의 반환값을 파싱할 수 밖에 없다. 성능이 나빠지고, 필요하지도 않은 작업이다. 또한 향후포맷을 바꾸면 시스템이 망가지는 결과를 초래할 수 있다.

---

toString 재정의 대상이 아닌 경우?

정적 유틸리티 클래스는 toString을 제공할 이유가 없다.

대부분의 열거타입도 자바가 이미 완벽한 toString을 제공하니 따로 재정의하지 않아도 된다.

하지만 하위 클래스들이 공유해야 할 문자열 표현이 있는 추상 클래스라면 toString을 재정의해줘야 한다.

 

아이템 10에서 소개한 구글의 AutoValue 프레임워크는 toStrin도 생성해준다.

AutoValue는 각 필드의 내용을 멋지게 나타내 주기는 하지만 클래스의 '의미'까지는 파악하지 못한다.

비록 자동 생성에 적합하지는 않더라도 객체의 값에 관해 아무것도 알려주지 않는 Object의 toString보다는 자동 생성된 toString이 훨씬 유용하다.

 

---

핵심 정리

모든 구체 클래스에서 Object의 toString을 재정의하자. 상위 클래스에서 이미 알맞게 재정의한 경우는 예외다. toString을 재정의한 클래스는 사용하기도 즐겁고 그 클래스를 사용한 시스템을 디버깅하기 쉽게 해준다. toString은 해당 객체에 관한 명확하고 유용한 정보를 읽기 좋은 형태로 반환해야 한다.