[이펙티브자바]toString을 항상 재정의하라_아이템12

1. 모든 하위 클래스에서 이 메서드를 재정의 해야 한다.
toString을 잘 구현한 클래스는 사용하기 훨씬 편하고, 그 클래스를 사용한 시스템은 디버깅하기 쉽다. 작성한 객체를 참조하는 컴포넌트가 오류 메시지를 로깅할 때 자동으로 호출할 수 있다. => toString을 제대로 재정의하지 않는다면 쓸모없는 메세지만 로그에 남을 것이다.
좋은 toString은 (특히 컬렉션처럼) 이 인스턴스를 포함하는 객체에서 유용하게 쓰인다.

[예제]
map객체 출력(toString 안했을 시): {jenny=PhoneNumber@adbbd}
map객체 출력(toString 했을 시): {jenny=010-1234-5678}
한 눈에 봐도 사용하기 수월하게 출력할 수 있다.

2. toString은 그 객체가 가진 주요 정보 모두를 반환하는 게 좋다. 테스트 실패 메시지는 toString에 주요 정보가 담기지 않았을 때 문제가 되는 대표적인 예다.

Assertion failure: expected {abc, 123}, but was {abc, 123}.
=> 실패: 예상값 {abc, 123}, 실제값 {abc, 123}
toString을 구현할 때면 반환값의 포맷을 문서화할지 정해야 한다. 포맷을 명시하면 csv파일처럼 사람이 읽을 수 있는 데이터 객체로 저장할 수 있다.

[단점]
포맷을 한번 명시하면 평생 그 포맷에 얽매이게 된다. 향후 릴리스에서 포맷을 바꾼다면 이를 사용하던 코드들과 데이터들은 엉망이 될것이다. 반대로 포맷을 명시하지 않는다면 향후 릴리스에서 정보를 더 넣거나 포맷을 개선할 수 있는 유연성을 얻게 된다.
즉, 포맷을 명시하든 아니든 의도는 명확히 밝혀야 한다. 하위 클래스들이 공유해야 할 문자열 표현이 있는 추상 클래스라면 toString을 재정의해줘야 한다.
대다수의 컬렉션 구현체는 추상 컬렉션 클래스들의 toString메서드를 상속해 사용한다.

끝으로 구글의 AutoValue 프레임워크는 toString도 생성해준다. => 클래스의 의미까지 파악하지는 못한다. 자동생성에 적합하지 않더라도 객체의 값에 관해 아무것도 알려주지 않는 Object의 toString보다 자동 생성된 toString이 훨씬 유용하다.