Effective Java 책을 보면 "항목 9. toString 메소드는 항상 재정의하는 것이 좋다."라는 항목이 있다. 이 항목의 내용 중 다음과 같은 내용이 있다.
toString 메소드가 리턴하는 문자열 형식을 정형화해서 API문서에 명세할 것인지 결정하는 것은 아주 중요한 문제이다. 그러나, 일단 toString이 리턴하는 문자열 형식을 정형화하여 명세화하고 나면 이 명세를 끝까지 지켜주어야 한다. 많은 프로그래머들이 toString의 명세에 따라 문자열을 구분분석(parse)하고, 생성하고, 저장하는 프로그램을 작성했는데, toString이 리턴하는 문자열 형식을 바꿔 버리면, 여기 저기서 프로그래머들이 울부짖는 소리를 들을 수 있을 것이다. 애초에 정형화된 문자열 형식을 명세하지 않아야 다음 배포판에서 문자열 형식을 개선하거나 정보를 마음대로 추가할 수 있다.
암튼... 이 포스트에서 강조하고 싶은 것은 toString 메소드에 의존하지 말고 toString 메소드가 리턴하는 문자열에 포함된 모든 정보에 접근할 수 있는 방법(예를 들어, 접근자)을 제공하는 것을 사용하라는 것이다. 만일 그러한 접근자가 없다면 그거 만든 놈한테 만들어 달라고 해라...=_=;;; 그것도 안돼면 Introduce Local Extension으로 리팩토링을 해라.
toString 메소드가 리턴하는 문자열 형식을 정형화해서 API문서에 명세할 것인지 결정하는 것은 아주 중요한 문제이다. 그러나, 일단 toString이 리턴하는 문자열 형식을 정형화하여 명세화하고 나면 이 명세를 끝까지 지켜주어야 한다. 많은 프로그래머들이 toString의 명세에 따라 문자열을 구분분석(parse)하고, 생성하고, 저장하는 프로그램을 작성했는데, toString이 리턴하는 문자열 형식을 바꿔 버리면, 여기 저기서 프로그래머들이 울부짖는 소리를 들을 수 있을 것이다. 애초에 정형화된 문자열 형식을 명세하지 않아야 다음 배포판에서 문자열 형식을 개선하거나 정보를 마음대로 추가할 수 있다.
암튼... 이 포스트에서 강조하고 싶은 것은 toString 메소드에 의존하지 말고 toString 메소드가 리턴하는 문자열에 포함된 모든 정보에 접근할 수 있는 방법(예를 들어, 접근자)을 제공하는 것을 사용하라는 것이다. 만일 그러한 접근자가 없다면 그거 만든 놈한테 만들어 달라고 해라...=_=;;; 그것도 안돼면 Introduce Local Extension으로 리팩토링을 해라.
공유하기 버튼
|
|
덧글