[Effective Java 3E] toString을 항상 재정의하라

💥 개요

Object의 기본 메서드는 적합한 문자열을 반환하는 경우가 거의 없습니다.

PhoneNumber@abddb 처럼 [클래스명@16진수로_표현한_해시코드]를 반환합니다.

읽기 불편하고,무슨 정보인지 클라이언트는 확인하기가 힘듭니다.

 

💡 toString 생성시 주의점

toString을 잘 구현한 클래스는 사용하기에 훨씬 즐겁고, 그 클래스를 사용한 시스템은 디버깅 하기가 쉽다.

toString 메서드는 객체를 println, printf, 문자열 연결 연산자(+), assert 구문에 넘길 때, 혹은 디버거가 객체를 출력할 때 자동으로 불립니다. 하지만 재정의를 하지 않는다면 그다지 쓸모없는 메시지가 출력될 것 입니다. map 객체를 출력할 때 

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

//toString 메서드를 정의하지 않은 경우
{jenny=PhoneNumber@abddb}

//toString 메서드를 잘 정의한 경우
{jenny=707-858-5309}

PhoneNumber용 toString을 제대로 정의했다면 위의 코드만으로 문제를 진단하기에 충분한 메시지를 남길 수 있습니다.

 

 

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

앞에서 전화번호 처럼 주요 정보를 모두 반환하는게 좋습니다. 하지만 객체가 거대하거나 객체의 상태가 문자열로 표현하기 적합하지 않다면 무리가 있습니다. "맨허튼 거주자 전화번호부(124214365개)"나 "Thread[main,5,main]" 같은 요약 정보나 이상적으로는, 완벽히 스스로를 설명하는 문자열을 담아야 합니다. (스레드는 뒤에 조건에 맞지않음)

다음 테스트 실패 메시지는 toString에 주요 정보가 담기지 않았을 때 문제가 되는 대표적 예시입니다.

Assertion failure: excepted {abc, 123}, but was {abc, 123}.

 

포맷을 명시할지, 안할지 명확히 밝혀야 한다.

전화번호나 행렬 같은 값 클래스라면 문서화 하기를 권장합니다. 그러면 그 객체는 그대로 입출력에 사용하거나 csv 파일로 저장할 수도 있습니다. 이때 포맷에 맞는 문자열과 객체를 상호 전환할 수 있는 정적 팩터리나 생성자를 함께 제공해주는것이 좋습니다. (BigInteger, BigDecimal)

private PhoneNumber(String phoneNumberString) {
    String[] split = phoneNumberString.split("-");
    this.areaCode = Short.parseShort(split[0]);
    this.prefix   = Short.parseShort(split[1]);
    this.lineNum  = Short.parseShort(split[2]);
}

public static PhoneNumber of(String phoneNumberString) {
    String[] split = phoneNumberString.split("-");
    PhoneNumber phoneNumber = new PhoneNumber(
            Short.parseShort(split[0]),
            Short.parseShort(split[1]),
            Short.parseShort(split[2]));
    return phoneNumber;
}

하지만, 한번 명시하면 평생 그 포맷에 얽히게 되는 단점이 있습니다. (향후 포맷을 변경하면 기존 코드에서 문제가 발생함)

명시하지 않는다면, 향후 정보를 더 넣거나,개선할 수 있는 유연성을 얻게 됩니다.

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

 

toString이 반환한 값에 포함된 정보를 얻어올 수 있는 API를 제공하자

PhoneNumber 클래스에서 지역코드, 프리픽스, 가입자 번호를 제공해야 합니다. (getPrefix와 같은) 그렇지 않으면 매번 toString의 값을 파싱해야하고(성능저하), 포맷이 바뀌면 시스템이 망가지는 결과가 나타납니다.

 

👍 toString을 재정의 하지 않아도 경우

1. 정적 유틸리티 클래스 - 제공 할 이유가 없다.
2. 열거 타입 - 자바가 이미 완벽한 toString을 제공한다.

하지만 하위 클래스가 공유할 문자열 표현이 있는 경우는 재정의 해줘야 합니다.

 

모든 구체 클래스에서 Object의 toString을 재정의하자. 상위 클래스에서 이미 알맞게 재정의한 경우는 예외다. toString을 재정의한 클래스는 사용하기도 즐겁고 그 클래스를 사용한 시스템을 디버깅 하기 쉽게 해준다. toString은 해당 객체에 관한 명확하고 유용한 정보를 읽기 좋은 형태로 반환해야 한다.