> For the complete documentation index, see [llms.txt](https://incheol-jung.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://incheol-jung.gitbook.io/docs/study/effective-java/undefined-1/2020-03-20-effective-12item.md).

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

equals와 hashCode만큼 대단히 중요하진 않지만 `toString`을 잘 구현한 클래스는 사용하기에 훨씬 즐겁고, 그 클래스를 사용한 시스템은 디버깅하기 쉽다.

toString을 제대로 재정의하지 않는다면 쓸모없는 메시지만 로그에 남을 것이다.

toString을 구현할 때면 반환값의 포맷을 `문서화`할지 정해야 한다. 포맷을 명시하면 그 객체는 표준적이고, 명확하고, 사람이 읽을 수 있게 된다. 따라서 그 값 그대로 입출력에 사용하거나 `CSV` 파일처럼 사람이 읽을 수 있는 데이터 객체로 저장할 수도 있다.

### 단점도 있다.

포맷을 한번 명시하면 (그 클래스가 많이 쓰인다면) 평생 `그 포맷에 얽매이게 된다.` 반대로 포맷을 명시하지 않는다면 향후 릴리스에서 정보를 더 넣거나 포맷을 개선할 수 있는 `유연성`을 얻게 된다.

### 포맷을 명시하든 아니든 여러분의 의도는 명확히 밝혀야 한다.

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

이전에 소개한 구글의 `AutoValue` 프레임워크는 toString도 생성해준다.

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

## 정리

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