다른 스터디원이 작성한 내용입니다.

• toString

<aside> 💡

규약 : 모든 하위 클래스에서 이 메서드를 재정의하라

</aside>

toString을 재정의 해야 하는 이유

• toString을 잘 구현한 클래스는 사용하기 편하고, 그 클래스에 대해 디버깅하기 쉽다.
• map 객체를 출력하는 경우 {Jenny=PhoneNumber@addbb}보다는 {Jenny=707-867-5308}이라는 메시지가 가독성이 좋다.
• 실전에서는 toString 메서드를 재작성할 때, 그 객체가 가진 주요 정보를 모두 반환하는 것이 좋다.
• toString을 구현할 때면 반환값의 포맷을 문서화할 지 정해야 한다.
• 값 클래스는 문서화를 권한다.
• 포맷을 명시하면, 그 객체는 표준적이고, 명확하고, 사람이 읽을 수 있게 된다.
• 포맷을 명시하기로 했으면, 명시한 포맷에 맞는 문자열과 객체를 상호전환할 수 있는 정적 팩터리나 생성자를 함께 제공하면 좋다.
• 단, 포맷을 한번 명시하면, 평생 그 포맷에 얽매이게 된다.
• 포맷을 명시하지 않는다면 다음 릴리즈에 포맷을 변경할 수 있는 유연성을 더 가져갈 수 있다.
• 포맷을 명시하든 아니든, 개발자의 의도는 명확히 밝혀야 한다.
• toString이 반환한 값에 대해 포함한 정보를 얻어올 수 있는 API를 제공하자
• toString에 있는 getter를 제공하지 않는다면, 클라이언트에서 toString을 파싱하여 사용할지도 모른다.

toString을 재정의 하지 않아도 되는 이유

• 정적 유틸리티 클래스는 따로 재정의하지 않아도 된다. (객체의 상태(state)를 가지는 클래스가 아니기 때문이다.)