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

• toString()의 일반 규약: 간결하면서 사람이 읽기 쉬운 형태의 유익한 정보
• toString()을 잘 구현한 클래스는 사용하기에 휠씬 즐겁고, 그 클래스를 사용한 시스템은 디버깅하기 쉽다.

좋은 toString()

• toString()을 제대로 재정의했다면, 출력문에 사용해서 쉽게 객체 내부의 정보를 확인할 수 있다.
• 객체가 가진 주요 정보 모두를 반환하는 게 좋다.
  • 그렇지 못했을 때 예외 발생 시, 해당 객체에 무슨 문제가 있는지 확인이 어렵다.
  • toString()을 구현할 때면 반환값의 포맷을 문서화할지 정해야 한다. (전화번호나 행렬 같은 값 클래스라면 문서화하자)
  • 문자열과 객체를 상호 전환할 수 있는 정적 팩터리나 생성자를 함께 제공해주면 좋다. ex) BigInteger, BigDecimal
• 단점: 포맷을 한번 명시하면 평생 그 포맷에 얽매이게 된다.
• 포맷을 명시하든 아니든 작성자의 의도는 명확히 밝혀야 한다.
• 포맷 명시 여부와 상관없이 toString()이 반환한 값에 포함된 정보를 얻어올 수 있는 API를 제공하자.
• 정적 유틸리티 클래스와 열거 타입(enum)는 toString()이 필요 없다.
• 하위 클래스들이 공유해야 할 문자열 표현이 있는 추상 클래스라면 toString()을 재정의해줘야 한다. ex) Collection 구현체에서 사용한다.
• IDE에서 자동 생성해주는 toString()이 Object의 toString()보다는 훨씬 유용하다.

핵심 정리

• 모든 구체 클래스에서 Object의 toString()을 재정의(오버라이드)하자
• 사용하기에도 즐겁고, 그 클래스를 사용한 시스템을 디버깅하기 쉽게 해준다.
• 해당 객체에 관한 명확하고 유용한 정보를 읽기 좋은 형태로 반환해야 한다.