Object의 기본 toString 메서드가 우리가 작성한 클래스에 적합한 문자열을 반환하는 경우는 거의 없다.
이 메서드는 PhoneNumber@adbbd 처럼 단순히 클래스_이름@16진수로_표시한_해시코드 를 반환할 뿐이다.
toString의 일반 규약에 따르면 '간결하면서 사람이 읽기 쉬운 형태의 유익한 ㅓㅇ보'를 반환해야 한다.
PhoneNumber@adbbd 는 간결하고 읽기 쉽다고 볼 수도 있지만 707-867-5309 처럼 전화번호를 직접 알려주는 형태가 훨씬 유익한 정보를 담고 있다.
또한 toString의 규약은 "모든 하위클래스에서 이 메서드를 재정의 하라" 고 한다.
equals와 hashCode 규약만큼 대단히 중요하진 않지만, toString을 잘 구현한 클래스는 사용하기에 훨씬 즐겁고, 그 클래스를 사용한 시스템은 디버깅 하기 쉽다.
toString 메서드는 객체를 println , printf , 문자열 연결 연산자(+), assert 구문에 넘길 때, 혹은 디버거가 객체를 출력할 떄 자동으로 불린다.
직접 호출하지 않어도 다른 어딘가에서 쓰인다는 이야기이다.
예컨대 ㅈ작성한 객체를 참조하는 컴포넌트가 오류 메시지를 로깅할 떄 자동으로 호출할 수 있다.
toString을 제대로 재정의 하지 않는다면 쓸모없는 메시지만 로그에 남을 것이다.
실전에서 toString은 그 객체가 가진 주요 정보 모두를 반환하는 게 좋다.
하지만 객체가 거대하거나 객체의 상태가 문자열로 표현하기에 적합하지 않다면 무리가 있다.
toString을 구현할 때면 반환값의 포맷을 문서화할지 정해야 한다.
이는 아주 중요한 선택이다. 전화번호나 행렬 같은 값 클래스라면 문서화하기를 권한다.
포맷을 명시하면 그 객체는 표준적이고, 명확하고, 사람이 읽을 수 있게 된다.
단점으로는 포맷을 명시하면 평생 그 포맷에 얽매이게 된다.
이를 사용하는 프로그래머들이 그 포맷에 맞춰 파싱하고, 새ㅔ로운 객체를 만들고, 영속 데이터로 저장하는 코드를 작성할 것이다.
반대로 포맷을 명시하지 않는다면 향후 릴리스에서 정보를 더 넣거나 포맷을 개선할 수 있는 유연성을 얻게 된다.
포맷을 명시하든 아니든 의도는 명확히 밝혀야한다.
포맷 명시여부와 상관없이 toString이 반환한 값에 포함된 정보를 얻어올수 있는 API를 제공하자
클래스에서 정보가 필요한 프로그래머는 toString의 반환값을 파싱할 수 밖에 없다.
성능이 나빠지고, 필요하지도 않은 작업이다.
게다가 향후 포맷을 바꾸면 시스템이 망가지는 결과를 초래할 수 있다.
접근자를 제공하지 않으면 그 포맷이 사실상 준-표준 API나 다름없어진다.
정적 유틸리티 클래스는 toString을 제공할 이유가 없다.
또한 대부분 열거타입도 자바가 이미 완벽한 toString을 제공하니 따로 재정의 하지 않아도 된다.
하지만 하위 클래스들이 공유해야 할 문자열 표현이있는 추상 클래스라면 toString을 재정의해줘야 한다.
예컨대 대다수의 컬렉션 구현체는 추상 컬렉션 클래스들의 toString메서드를 상속해 쓴다.
모든 구체 클래스에서 Object의 toString을 재정의 하자.
상위 클래스에서 이미 알맞게 재정의한 경우는 예외다.
toString을 재정의한 클래스는 사용하기도 쉽고 그 클래스를 사용한 시스템을 디버깅하기 쉽게 해준다.
toString은 해당 객체에 관한 명확하고 유용한 정보를 읽기 좋은 형태로 반환해야 한다.