[3장. 모든 객체의 공통 메서드] - '아이템 12. toString을 항상 재정의하라' 추가

이펙티브 자바 (Effective Java)/src/chapter3/item12/item12.md

@@ -0,0 +1,45 @@
+# 아이템 12. toString을 항상 재정의하라
+
+- Object의 기본 toString 메서드는 단순히 **클래스_이름@16진수로_표시한_해시코드**를 반환할 뿐이다.
+- toString의 일반 규약에 따르면 '간결하면서 사람이 읽기 쉬운 형태의 유익한 정보'를 반환해야 한다.
+
+#### toString의 규약은 "모든 하위 클래스에서 이 메서드를 재정의하라"고 한다.
+
+- **toString을 잘 구현한 클래스는 사용하기에 훨씬 즐겁고, 그 클래스를 사용한 시스템은 디버깅하기 쉽다.**
+- toString 메서드는 객체를 println, printf, 문자열 연결 연산자(+), assert 구문에 넘길 때, 혹은 디버거가 객체를 출력할 때 자동으로 불린다.
+
+## 좋은 toString
+
+- 좋은 toString은 (특히 컬렉션처럼) 이 인스턴스를 포함하는 객체에서 유용하게 쓰인다.
+- **실전에서 toString은 그 객체가 가진 주요 정보 모두를 반환하는 게 좋다.**
+- 하지만 객체가 거대하거나 객체의 상태가 문자열로 표현하기에 적합하지 않다면 요약 정보를 담아야 한다.
+- 이상적으로는 스스로를 완벽히 설명하는 문자열이어야 한다.
+
+## toString을 구현할 때면 반환값의 포맷을 문서화할지 정해야 한다.
+
+- 포맷을 명시하기로 했다면, 명시한 포맷에 맞는 문자열과 객체를 상호 전환할 수 있는 정적 팩터리나 생성자를 함께 제공해주면 좋다.
+- 자바 플랫폼의 많은 값 클래스가 따르는 방식이며, BigInteger, BigDecimal과 대부분의 기본 타입 클래스가 여기 해당한다.
+- 주의해야 할 점으로는, 반환값의 포맷을 한번 명시하면 (그 클래스가 많이 쓰인다면) 평생 그 포맷에 얽매이게 된다.
+- 반대로 포맷을 명시하지 않는다면 향후 릴리스에서 정보를 더 넣거나 포맷을 개선할 수 있는 유연성을 얻게 된다.
+
+## 포맷을 명시하든 아니든 의도는 명확히 밝혀야 한다.
+
+- 포맷을 명시하려면 아주 정확하게 해야 한다.
+- 포맷 명시 여부와 상관없이 **toString이 반환한 값에 포함된 정보를 얻어올 수 있는 API를 제공하자.**
+- 즉, 정보에 대한 접근자를 제공해야 한다. 그렇지 않으면 이 정보가 필요한 시점에 toString의 반환값을 파싱할 수 밖에 없다.
+- 성능이 나빠지고 필요하지도 않은 작업이다. 게다가 향후 포맷을 바꾸면 시스템이 망가지는 결과를 초래할 수 있다.
+- 접근자를 제공하지 않으면 (변경될 수 있다고 문서화했더라도) 그 포맷이 사실상 준-표준 API나 다름없어진다.
+
+## toString과 정적 유틸리티 클래스, 열거 타입, 추상 클래스
+
+- 정적 유틸리티 클래스는 toString을 제공할 이유가 없다.
+- 대부분의 열거 타입도 자바가 이미 완벽한 toString을 제공하니 따로 재정의하지 않아도 된다.
+- 하지만 하위 클래스들이 공유해야 할 문자열 표현이 있는 추상 클래스라면 toString을 재정의해줘야 한다.
+    - 예를 들어, 대다수의 컬렉션 구현체는 추상 컬렉션 클래스들의 toString 메서드를 상속해 쓴다.
+
+#### 객체의 값에 관해 아무것도 알려주지 않는 Object의 toString보다는 자동 생성된 toString이 훨씬 유용하다.
+
+## 핵심 정리
+
+모든 구체 클래스에서 Object의 toString을 재정의하자. 상위 클래스에서 이미 알맞게 재정의한 경우는 예외다. toString을 재정의한 클래스는 사용하기도 즐겁고 그 클래스를 사용한 시스템을 디버깅하기
+쉽게 해준다. toString은 해당 객체에 관한 명확하고 유용한 정보를 읽기 좋은 형태로 반환해야 한다.