sjchoi’s Blob
자긍심이 없는 것은 우리를 모르기 때문이다.

Effective Java Programming Language Guide

자바라는 프로그래밍 ‘언어’를 정확하고 유창하게 쓸 수 있도록 도와주는 지침서로서, 기본 자바 플랫폼 라이브러리인 java.lang, java.util, java.io(일부)를 다룬다. 물론, 다른 라이브러리들도 조금씩 다루기는 하지만, 그래픽 사용자 인터페이스(GUID) 프로그래밍이나 엔터프라이즈 API는 다루지 않는다.

이 책은 57개 항목으로 나뉘어져 있고, 하나의 항목에서 하나의 프로그래밍 규칙을 소개한다. 이 프로그래밍 규칙들은 모두 뛰어난 프로그래머들의 유용한 경험을 모은 것이다. 소프트웨어 설계의 관점에서 이 항목들은 다시 크게 9개 장으로 나뉜다. 각 항목은 거의 다른 항목들과 크게 연관이 없고, 항목들 사이의 상호 참조를 친절하게 달아 놓았으므로 자신이 원하는 곳부터 마음대로 읽으면 된다. Yes24 책 소개

 주요내용

  1. 쓰지 않는 리퍼런스는 g.c을 위해 null 할당(jvm마다 다르긴 하지만 해주는 것이 훨씬 좋다.)
  2. equals 구현 스펙 준수
    2-1. equals, hashCode 는 항상 같이 재정의
    2-2. hashCode 재정의 시에는 해쉬버킷에 골고루 들어가도록 정의하자.
  3. toString을 명세화하면 여러가지로 써먹을 수 있다.
    -> 객체의 문자열 정보에 접근하는 사실 상의 표준 api로 사용할 수 있다.
     -> 물론 이 경우에는 toString의 반환 형식을 명세화해야한다.
  4. Clonable의 clone 메소드는 신중하게 재정의(shallow copy<->deep copy, primitive 값등에 대해)
  5. Comparable interface, general (nature order)
     -> Comparator interface 특정 방식의 order가 필요할 때
  6. final은 가리키고 있는 리퍼런스 값만을 바꾸지 않는다. 만일 immutable 객체가 아니라면 허점이 생길 수 있다.
  7. 대부분의 경우 immutable class, deligate pattern이 유리하다.
  8. 인터페이스는 타입을 정의할 때만 사용한다. & 대부분의 경우 인터페이스를 사용한다
  9. immutable 클래스에서 클래스 내부 프로퍼티의 리퍼런스를 반환하면 리퍼런스를 통해 조작될 수 있기 때문에 immutable 이 아니다.
    -> clone 등을 통해 안전하게 반환한다.
  10. overloading 메소드 이름은 같고 인자만 다른 것->컴파일타임에 결정
    overridding 시그네이쳐가 완전히 같은 것(상속 관계)->런타임에 결정
  11. null을 반환하지 말자. 반환받는 쪽에서 처리해야 할 예외가 하나 더 추가된다.
     -> 빈 배열이나 컬렉션을 반환하자
     -> 성능 상의 문제라면 빈 배열이나 컬렉션을 static 으로 선언해놓는다.
      -> 표준 형식(canonical form)으로 클래스 내부에 저장하면 유리한 점이 많다.
  12. 지역변수의 범위는 항상 최소로, 블럭의 맨 위가 아니라 쓸 곳에서 선언
    12-1. for(int i=0, j=list.size();i<n;i++){…}
     -> while 보다 유리한 점이 많다.
    * 널 반환이나 블럭 맨 위의 지역변수 선언은 C 스타일에서 온 것, 자바에는 어울리지 않는다.
  13. 정확한 계산을 위해서는 부동 소수점은 절대 사용하지 않는다.
  14. 원하는 기능의 대부분은 표준 라이브러리에 있다. 안정적, 능률적이다. 괜한 기능 다시 만들 필요 없다.
  15. 성급한 최적화는 모든 죄악의 근원이다. – Donald E. Knuth
  16. naming convention은 항상 지킬것! – 확실치 않을때는 표준 API를 참고할 것
    -> 주의할 것, 우리는 객체를 만드는 것이지 JavaBean을 만드는 것이 아니라는 것을 명심!
  17. Checked Exception 에 대한 고민이 필요하다.
    -> Checked Exception 을 사용할 것인지…
    -> 예외처리의 분산, 클래스 구현의 예외성 증가
  18. 재사용을 위해 표준예외를 사용할 것
  19. 하위 레벨의 예외를 적절히 상위 레벨의 예외로 추상화한다. 하지만 능사는 아니고 예외의 원인 자체를 원천적으로 없애는 것이 제일이다.(Checked Exception 이라면)
  20. 예외 때문에 메소드 호출이 실패해도 객체상태는 메소드 호출 전과 같아야 한다.
  21. 쓰레드 & 동기화에 대해 스펙을 자세히 볼 것!
    -> 쓰레드 등에 대한 믿을만한 고수준 라이브러리가 있으면 그것을 사용할 것(CSP)
    -> 쓰레드는 아무리 간단해도 일반적인 이해를 통해 사용하긴 무리가 따른다.
    -> 구현 상 필요할 때만 사용하고 고수준 라이브러리를 사용할 것.
  22. Double Checked Lock은  제대로 돌아가지 않는다.
  23. volatile 은 JVM마다 구현과 작동이 다르다. 요주의!
  24. 동기화 블럭 안에서 재정의 할 수 있는 public, protected 메소드를 호출하지 말것.
    24-1. 동기화 블럭 안에서는 작업을 조금만 처리하는 것을 원칙으로 삼아야한다.
  25. wait 메소드는 항상 반복문 안에서 실행한다. 그러면 좀더 안전한 notifyAll을 제약없이 사용할 수 있다.
    25-1. notifyAll 대신 notify 를 쓰려면(성능상의 이유로) 쓰레드의 건정성을 확실히! 보장해야 한다.
  26. 쓰레드 스케줄러를 믿지 말것, yield 같은 메소드 우선순위도 믿지 말것, 쓰레드 자체를 어떻게 해보려고 하지도 말 것
    -> 해결책은 원칙을 지키는 것! 
    -> 쓰레드에 영향 받는 코드를 최소한으로 줄이고
    -> 강건하고 건전한 코드를 만들자
  27. 27. 쓰레드 안전성에 관해 반드시 문서화 할것
    -> immutable, thread-safe 등
  28. 쓰레드 그룹도 쓰지 말 것, 페물이나 다름없다!
  29. 직렬화는 신중하게 사용한다, 그냥 쓰기는 쉽지만 이후 추가 구현 등에서 발목 잡는다.
  30. 직렬화<->역직렬화는 주의깊게 구현한다.(immutable 경우)
Advertisements

응답 없음 to “Effective Java Programming Language Guide”

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중

%d 블로거가 이것을 좋아합니다: