일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
Tags
- 자바스터디
- 람다식
- 함수형 인터페이스
- docker
- 접근지시자
- System.out
- raw 타입
- 스파르타코딩클럽
- 로컬 클래스
- 상속
- 자바할래
- yield
- auto.create.topics.enable
- System.err
- throwable
- System.in
- github api
- 합병 정렬
- 제네릭 타입
- 프리미티브 타입
- 정렬
- annotation processor
- junit 5
- Study Halle
- 제네릭 와일드 카드
- 항해99
- 브릿지 메소드
- 바운디드 타입
- Switch Expressions
- 익명 클래스
Archives
- Today
- Total
코딩하는 털보
이펙티브 자바, 아이템 12. toString을 항상 재정의하라 본문
이펙티브 자바, 아이템 12. toString을 항상 재정의하라
toString의 일반 규약, 간결하면서 사람이 읽기 쉬운 형태의 유익한 정보, 모든 하위 클래스에서 이 메서드를 재정의하라.
Object의 기본 toString은 클래스이름@16진수해시코드를 반환하며, 그다지 쓸모 없는 메시지를 출력하게 된다.
toString을 잘 구현한 클래스는 사용하기에 훨씬 즐겁고, 그 클래스를 사용한 시스템은 디버깅하기 쉽다.
toString은 우리가 직접 호출하지 않아도 다른 어딘가에서 쓰일 수 있다.
실전에서 toString은 그 객체가 가진 주요 정보를 모두 반환하는 게 좋다.
PhoneNumber에서 지역 번호만 toString에 담았다고 가정한다.
@Override
public String toString() {
return "PhoneNumber{" +
"ariaCode=" + ariaCode +
'}';
}
그러면 아래와 같은 테스트에서 테스트 결과 출력으로 문제를 발견하기 어려워진다.
@Test
public void createPhoneNumber() {
PhoneNumber phoneNumber1 = new PhoneNumber(123,456,7890);
PhoneNumber phoneNumber2 = new PhoneNumber(123,456,7891);
assertThat(phoneNumber1).isEqualTo(phoneNumber2);
// 출력 결과
// Expected :PhoneNumber{ariaCode=123}
// Actual :PhoneNumber{ariaCode=123}
}
예외적으로,
정적 유틸리티 클래스는 toString을 제공할 이유가 없다.
대부분의 열거 타입은 자바가 이미 완벽한 toString을 제공하므로 따로 재정의할 필요가 없다.
그러나 하위 클래스들이 공유할 문자열 표현이 있는 추상클래스는 toString을 재정의해준다.
Comments