<aside> 💡 Object 의 기본 toString 메서드가 우리가 작성한 클래스에 적합한 문자열을 반환하는 경우는 거의 없다!

</aside>

• 단순히 클래스 이름@16진수로 표현한 해시코드 를 반환한다.
  • toString 은 간결하면서 사람이 읽기 쉬운 형태의 유익한 정보를 반환해야 한다!
  • 규약에서는 모든 하위 클래스에서 이 메서드를 재정의하라고 나와있다.

equals 와 hashCode 만큼 중요하진 않지만, toString 을 잘 구현한 클래스는 사용하기 즐겁고, 디버깅하기 쉽다.

• toString 메서드는 객체를 println , printf , + , assert 구문에 넘길 때, 디버거가 객체를 출력할 때 자동으로 불린다.

  • 우리가 직접 호출하지 않아도 다른 어딘가에서 쓰인다.

• phoneNumber 용 toString 을 제대로 재정의했다면, 다음 코드만으로 문제를 진단하기에 충분한 메시지를 남길 수 있다.

System.out.println(phoneNumber + "에 연결할 수 없습니다.");

• toString 을 재정의했든 아니든 대부분은 진단 메시지를 위와 같이 만든다.
  • 재정의를 하지 않았다면 그다지 쓸모가 없는 메시지가 출력된다.
  • 좋은 toString 은 이 인스턴스를 포함하는 객체에서 유용하게 쓰인다.

실전에서 toString 은 그 객체가 가진 주요 정보 모두를 반환하는게 좋다.

• ex) {Jenny=PhoneNumber@adbbd} 보다는, {Jenny=707-867-5309}

  • 하지만 객체가 거대하거나 객체의 상태가 문자열로 표현하기에 적합하지 않다면 무리가 있다.
  • 이런 경우는 스스로를 완벽히 설명하는 요약 정보를 문자열로 담아야 한다.

• toString 을 구현할 때면 반환값의 포맷을 문서화할지 정해야 한다.

  • 전화번호나 행렬 같은 값 클래스라면 문서화하기를 권한다.
    • 포맷을 명시하면 표준적이고, 명확하고, 사람이 읽을 수 있게 된다.
    • 그 값 그대로 입출력에 사용하거나, CSV 파일처럼 사람이 읽을 수 있는 데이터 객체로 저장할 수도 있다.
  • 포맷을 명시하기로 했다면, 명시한 포맷에 맞는 문자열과 객체를 상호 전환할 수 있는 정적 팩터리나 생성자를 함께 제공해주면 좋다.

포맷을 문서화하는 것의 단점?

• 포맷을 한번 명시하면 평생 그 포맷에 얽매이게 된다.
  • 이를 사용하는 프로그래머들이 그 포맷에 맞춰 파싱하고, 객체를 만들고, 영속 데이터로 저장하는 코드를 작성한다.
  • 반대로 포맷을 명시하지 않게 되면 향후 릴리스에서 정보를 더 넣거나 포맷을 개선할 수 있는 유연성을 얻게 된다.

포맷을 명시하든 아니든 우리의 의도는 명확히 밝혀야 한다.