이번장의 핵심은...
모든 구체 클래스에서 Object의 toString을 재정의하자
상위 클래스에서 이미 알맞게 재정의한 경우는 예외이다
toString은 해당 객체에 관한 명확하고 유용한 정보를 읽기 좋은 형태로 반환해야 한다
Object의 Default toString 메서드는 작성한 클래스의 적합한 문자열을 반환하는 경우는 거의 없다
1. Object의 Default toString 메서드는 단순히 클래스 이름@16진수 해쉬 코드를 반환한다
ex) 클래스 이름이 Jackcoding이면, Jackcoding@adbbd
2. toString의 일반 규약에 따르면 '간결하고 사람이 읽기 쉬운 형태의 유익한 정보'를 반환해야 한다
3. toString을 잘 구현한 클래스는 사용하기에 즐겁고, 디버깅이 쉽다
4. 만약 toString을 재정의하지 않으면 쓸모없는 메시지만 로그에 남을 것이다
toString은 그 객체가 가진 주요 정보를 모두 반환하는게 좋다
1. 하지만, 객체가 거대하거나 객체 상태가 문자열로 표현하기에 적합하지 않으면 무리가 있다
2. toString을 구현할 때면 반환값의 포맷을 문서화할지 정해야 한다
전화번호나 행렬 같은 값 클래스라면 문서화하는게 좋다
포맷을 명시하면 표준적이고 명확하고 사람이 읽을 수 있다
그 값 그대로 입출력에 사용하거나 CSV 파일로 저장도 가능하다
정적 팩터리나 생성자를 함께 제공해주면 좋음
ex) BigInteger, BigDecimal
단점으로는 평생 그 포맷에 얽매이게 된다
향후 포맷을 바꾸면 기존 코드들과 데이터는 엉망이 될 것이다
포맷을 명시하지 않으면 향후 릴리스에서 정보를 더 넣거나 포맷을 개선할 수 있는 유연성을 가질 수 있다
포맷을 명시하든 아니든 의도는 명확히 밝혀라
포맷을 명시하려면 아주 정확하게 명시하자
// 구체적으로 포맷을 명시한 경우
/**
* 이 전화번호의 문자열 표현을 반환한다.
* 이 문자열은 "XXX-YYY-ZZZZ" 형태의 12글자로 구성된다.
* XXX는 지역코드, YYY는 프리픽스, ZZZ는 가입자 번호다.
**/
@Override
public String toString() {
return String.format("%03d-%03d-%04d, areaCode, prefix, lineNum");
}
// 포맷을 명시하지 않기로한 경우
/**
* 이 약물에 관한 대략적인 설명을 반환
* 다음은 이 설명의 일반적인 형태이나,
* 상세 형식은 정해지지 않았으며 향후 변경될 수 있음
* [약물 #9 : 유형=사랑, 냄새=테레빈유, 겉모습=먹물]
**/
@Override
public String toString() {...}
toString 반환 값의 정보를 API로 제공하자
포맷 명시 여부와 상관없이 toString이 반환한 값에 포함된 정보를 얻어올 수 있는 API를 제공하면 좋다
toString의 반환 값을 파싱 하면 성능이 나빠지고, 필요하지도 않은 작업이다
또한, 포맷을 바꾸면 시스템이 망가지는 결과를 초래할 수 있다
toString을 재정의하지 않아도 되는 경우
정적 유틸리티 클래스는 toString을 제공할 이유가 없고,
열거 타입도 자바가 이미 완벽한 toString을 제공 중이니 따로 재정의하지 않아도 된다
추상 클래스는 재정의해주자
'Java > Effective Java 3E' 카테고리의 다른 글
[이펙티브자바 3판] ITEM14. Comparable을 구현할지 고려하라 (0) | 2020.09.14 |
---|---|
[이펙티브자바 3판] ITEM13. clone 재정의는 주의해서 진행하라 (0) | 2020.09.13 |
[이펙티브자바 3판] ITEM11. equals를 재정의하려거든 hashCode도 재정의하라 (0) | 2020.09.12 |
[이펙티브자바 3판] ITEM10. equals는 일반 규약을 지켜 재정의하라 (0) | 2020.09.11 |
[이펙티브자바 3판] ITEM9. try-finally 보다는 try-with-resources를 사용하라 (0) | 2020.09.09 |
댓글