DEV ℧ Developer Diary

[EffectiveJava] item12 - toString을 항상 재정의하라.

28 Apr 2022

toString을 항상 재정의하라.

Object의 객체들을 System.out.println();으로 감싸보자.

그러면 클래스의 해당하는 문자열을 반환하는 경우는 거의 없고 java.lang.Object@3ac3fd8b와 같은 클래스_이름@16진수로_표현한_해시코드를 반환 할 뿐이다.

toString의 일반 규약에 따르면 ‘간결하면서 사람이 읽기 쉬운 형태의 유익한 정보’를 반환 해야 한다.

만약 item11에서 사용한 PhoneNumber객체를 toString해보자, com.package.PhoneNumber@2aga64db와 같은 정보들 보다는 number="707-4822-3311"와 같은 전화번호를 직접 알려주는 형태가 더욱 유익한 정보를 담고있을 수 있다.

또한 toString의 규약은 ‘모든 하위 클래스에서 이 메서드를 재정의하라’고 한다.

왜 toString을 재정의 해야할까?

toString을 잘 구현한 클래스는 사용하기에 더욱 편하고, 그 클래스를 사용한 시스템은 디버깅하기가 쉽다. 만약 시스템에 오류에 관련된 로그를 남긴다 하더라도 재정의 하지않는다면, 오류의 메시지가 아닌 쓸모없는 메시지만 로그에 남을 것이다.

예를들어 PhoneNumber객체에 대한 toString을 제대로 재정의햇다면 다음 코드만으로 문제를 진단하기에 충분 할 수 있다.

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

또한 실전에서 toString은 그 객체가 가진 주요 정보 모두를 반환하는 게 좋다. 앞서 전화번호 객체 처럼 말이다.

하지만 단점도 존재한다. 자주쓰이는 클래스에 대한 포맷을 한번 명시하면 평생 그 포맷에 얽매이게 된다. 수많은 개발자들이 해당 포맷을 토대로 코드를 작성하게 될것이고, 향후 릴리즈에 포맷이 변경된다면 이를 사용하던 코드들과 데이터들은 엉망이 될 것이다. 반대로 포맷을 명시하지 않는다면 향후 릴리스에 정보를 더넣거나 포맷을 개선할 수 있는 유연성을 얻게된다.

그러므로 포맷을 명시하든 아니든 코드에 대한 의도는 명확히 밝혀야 한다.

예를 들어 item11의 PhoneNumber객체를 보자. 아래는 포맷을 명시한 예와 명시하지 않은 예시이다.

  • 포맷을 명시
/**
 * 이 전화번호의 문자열 표현을 반환한다.
 * 이 문자열은 "XXX-YYY-ZZZZ" 형태의 12글자로 구성된다.
 * XXX는 지역 코드, YYY는 프리픽스, ZZZZ는 가입자 번호다.
 * 각각의 대문자는 10진수 숫자 하나를 나타낸다.
 *
 * 전화번호의 각 부분의 값이 너무 작아서 자릿수를 채울 수 없다면,
 * 앞에서부터 0으로 채워나간다. 예컨대 가입자 번호가 123이라면
 * 전화번호의 마지막 네 문자는 "0123"이 된다.
 */
@Override
public String toString() {
    return String.format("%03d-%03d-%04d",areaCode, prefix, lineNum);
}
  • 포맷을 명시하지 않음
/**
 * 이 약물에 관한 대략적인 설명을 반환한다.
 * 다음은 이 설명의 일반적인 형태이나,
 * 상세 형식은 정해지지 않았으며 향후 변경될 수 있다.
 *
 * "[약물 #9: 유형=사랑, 냄새=테레빈유, 겉모습=먹물]"
 */
@Override
public String toString() {
    ...
}

이러한 포맷 명시 여부와 상관 없이 toString이 반환한 값에 포함된 정보를 얻어올수 있는 API를 제공하자.

정적 유틸리티 클래스의 경우 toString을 제공할 이유가 없다. 또한 대부분의 열거타임 도 자바가 이미 완벽한 toString을 제공하니 따로 재정의 하지 않아도 된다. 하지만 하위 클래스들이 공유해야 할 문자열 표현이 있는 추상 클래스라면 toString을 재정의 해줘야 한다.

Related posts