Languages/Java2014.09.05 12:23

이펙티브 자바(Effective Java)의 2판이 다시 번역되어 재출간되었습니다. 출판사는 인사이트입니다. 





원래 대웅출판사에서 번역되어 출간되었다가 절판된 것을 이번에 인사이트에서 다시 번역해서 출간했습니다. 원래 번역본을 전혀 참고하지 않은, 전면적인 재 번역입니다. 


참고하시라고, 118페이지의 본문을 발췌해 보았습니다. 


규칙 16은 계승을 위한 설계와 문서를 갖추지 않은 “이질적(foreign)” 클래스의 하위 클래스를 만들 때 생기는 문제점을 설명하고 있다. 그렇다면 계승을 위한 설계와 문서를 갖춘다는 것은 어떤 의미일까?


우선, 메서드를 재정의하면 무슨 일이 생기는지 정확하게 문서로 남겨야 한다. 다시 말해, 재정의 가능 메서드를 내부적으로 어떻게 사용하는지(self-use) 반드시 문서에 남기라는 것이다. public이나 protected로 선언된 모든 메서드와 생성자에 대해, 어떤 재정의 가능 메서드를 어떤 순서로 호출하는지, 그리고 호출 결과가 추후 어떤 영향을 미치는지 문서로 남기라는 것이다. (재정의 가능하다는 것overridable은 public 또는 protected로 선언된 비-final 메서드라는 뜻이다.) 좀 더 일반적으로 이야기하자면, 재정의 가능 메서드가 호출되는 모든 상황을 문서로 남기라는 것이다. 예를 들어, 후면(background) 스레드가 호출할 수도 있고, static 초기화 구문(initializer) 안에서 호출할 수도 있다.


관습적으로, 재정의 가능 메서드를 어떤 식으로 호출하는지는 메서드 주석문 마지막에 명시한다. 주석은 “이 구현은”이라는 문구로 시작한다. 릴리스에 따라서 달라질 수 있다는 뜻으로 하는 말은 아니며, 메서드 내부 동작 원리에 관한 주석이라는 뜻이다. 아래에 java.util.AbstractCollection 명세에서 가져온 예제를 보였다.


170페이지, 규칙 26 관련 본문도 한번 보겠습니다.


컴파일러는 프로그램의 형 안전성을 입증할 수 없을지 모르지만, 프로그래머는 할 수 있다. 무점검 형변환(unchecked cast)을 하기 전에 개발자는 반드시 그런 형변환이 프로그램의 형 안전성을 해치지 않음을 확실히 해야 한다. 위에서 문제가 되고 있는 배열 elements는 private 필드이고 클라이언트에 반환되지 않으며 다른 어떤 메서드에도 전달되지 않는다. push 메서드에 전달되는 원소만이 배열에 저장되며, 그 타입은 전부 E다. 따라서 무점검 형변환을 해도 아무런 문제가 없다.


무점검 형변환이 안전함을 증명했다면, 경고를 억제하되 범위는 최소한으로 줄여야 한다(규칙 24). 위의 예제의 경우, 생성자에 있는 코드라고는 무점검 배열 생성을 하는 코드가 전부이므로 생성자 전체적으로 경고를 억제해도 무방하다. 경고를 억제하는 어노테이션을 추가하고 나면 Stack 클래스는 아무 문제없이 컴파일 될 것이며, 명시적인 형변환이나 ClassCastException이 발생할 걱정없이 사용할 수 있게 된다.


Java 1.8이 공개된 시점이지만, 이 책의 많은 부분은 아직도 유효한 교훈들을 담고 있습니다. 최신 Java와 많이 달라진 부분에는 제한적이지만 주석이 달려 있어서, 1.8에서 해결된 것이 무엇인지 살펴볼 수 있도록 약간의 배려도 하고 있습니다.


저작자 표시 비영리 변경 금지
신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

  1. 지나가던개발자

    예로 보여주신, Item17대목요...

    Inheritance를 계승이라 번역하시고, foreign class를 '이질적 클래스'라고 하셨는데..
    inheritance는 이제 '상속'이라는 말로 통용되고,
    foreign class는 이전 아이템(16)의 주제를 보면 '패키지 외부의 클래스' 정도로 이해되는데..

    다른 의도가 있으셨던 건가요?

    2014.09.22 15:19 신고 [ ADDR : EDIT/ DEL : REPLY ]
    • 내가 설계하지 않은 클래스라는 의미를 좀 더 잘 전달할 용어를 찾았던 것인데, 지금 다시 살펴보니 좀 오버한 것 같기도 합니다. 그래서 가급적이면 영어 원문을 병기하였사오나, 혼란이 있으셨다면 사과드립니다.

      2014.09.24 11:54 신고 [ ADDR : EDIT/ DEL ]
  2. 여전히 지나가는 개발자

    2017년임에도 이 책을 가지고 스터리를 하고 있습니다. 몇몇 오타가 보이는데 오정표가 따로 있는지요? 아니면 재판계획이 있으신지요? 워낙에 명저라 관심이 많습니다.

    2017.03.19 17:54 신고 [ ADDR : EDIT/ DEL : REPLY ]