(이펙티브 자바 3) 12. toString을 항상 재정의하라

toString을 잘 구현한 클래스는 사용하기에 훨씬 즐겁고, 그 클래스를 사용한 시스템은 디버깅하기 쉽다. Object의 기본 toString 메서드는 우리에게 적합한 문자열을 잘 반환해주지 않기 때문에 toString의 일반 규약에 따라 간결하면서 사람이 읽기 쉬운 형태의 유익한 정보를 반환하도록 재정의할 필요가 있다.

toString 규약

실전에서 toString은 그 객체가 가진 주요 정보 모두를 반환하는 게 좋다. 만약 객체가 거대하거나 객체의 상태가 문자열로 표현하기에 적합하지 않다면 요약 정보를 담아 전달해 줄 수 있어야 한다.

toString 포맷

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

포맷 문서화의 단점도 존재한다. 한번 명시된 포맷으로 인해 프로그래머들은 그 포맷에 맞춰 파싱하고, 새로운 객체를 만들고, 영속 데이터로 저장하는 코드를 작성할 것이다. 하지만 향후 릴리스에서 포맷을 바꾼다면 이를 사용하던 코드들과 데이터들은 엉망이 될 것이다.

포맷을 명시하든 아니든 의도를 명확히 밝혀줄 필요가 있다. 주석을 통해 이를 해결할 수 있으며 포맷을 명시하기로 했다면 아주 정확하게 가이드를 제시하여야 한다.

toString이 참조하는 값과 API

포맷 여부와 상관없이 toString이 반환할 값과 포함된 정보를 얻어올 수 있는 API를 제공하자. 그렇지 않으면 toString의 포맷을 파악하고 반환값을 파싱 하여 이용해야 하는데, 이렇게 할 경우 성능이 나빠지며 필요하지 않을 작업(조합(toString)과 분해(Parsing))을 하게 되는 것이다. 또한 포맷의 변경이 일어난다면 이를 파싱 해 사용하던 시스템에도 심각한 문제를 초래할 수 있다.

AutoValue와 toString

앞서 살펴본 아이템 10과 11 (equals & hashCode)는 구글에서 제공하는 AutoValue 프레임워크를 이용하여 생성할 수 있다. 물론 toString도 마찬가지이다. AutoValue는 각 필드의 내용을 멋지게 나타내 준다. 하지만 클래스의 의미까지는 파악하지 못한다. 아무래도 toString은 사람이 읽기 쉬운 유익한 정보를 반환해야 하기 때문에 자동 생성에 적합하지 않다고 생각한다 (하지만 Object가 자동으로 생성해주는 toString보다는 훨씬 유익할 수 있다).

---

정리

모든 구체 클래스에서는 Object의 toString을 재정의하자. 상위클래스에서 이미 알맞게 재정의가 되어있다면 이 과정은 생략해도 된다. 재사용이나 디버깅을 위해서라도 toString은 항상 해당 객체에 대해 명확하고 유용한 정보를 반환할 수 있도록 만들어주자.