상세 컨텐츠

본문 제목

Effective Java 2/E 스터디

SW/미분류

by 푸로그 2019. 6. 19. 00:10

본문

일정

6월 19일 8장 프로그래밍 일반

6월 21일 7장 메소드

6월 25일 6장 열거형과 주석
6월 27일 9장 예외

7월 2일 2장 객체의 생성과 소멸
7월 5일 3장 모든 객체에 공통적인 메소드

7월 9일 4장 클래스와 인터페이스
7월 12일 5장 제네릭

7월 16일 10장 동시성
7월 19일 11장 직렬화

**책의 목차**
2장 객체의 생성과 삭제 

규칙 1 생성자 대신 정적 팩터리 메서드를 사용할 수 없는지 생각해 보라 
규칙 2 생성자 인자가 많을 때는 Builder 패턴 적용을 고려하라. 
규칙 3 private 생성자나 enum 자료형은 싱글턴 패턴을 따르도록 설계하라 
규칙 4 객체 생성을 막을 때는 private 생성자를 사용하라 
규칙 5 불필요한 객체는 만들지 말라 
규칙 6 유효기간이 지난 객체 참조는 폐기하라 
규칙 7 종료자 사용을 피하라 

3장 모든 객체의 공통 메서드 

규칙 8 equals를 재정의할 때는 일반 규약을 따르라 
규칙 9 equals를 재정의할 때는 반드시 hashCode도 재정의하라 
규칙 10 toString은 항상 재정의하라 
규칙 11 clone을 재정의할 때는 신중하라 
규칙 12 Comparable 구현을 고려하라 

4장 클래스와 인터페이스 91 

규칙 13 클래스와 멤버의 접근 권한은 최소화하라 
규칙 14 public 클래스 안에는 public 필드를 두지 말고 접근자 메서드를 사용하라 
규칙 15 변경 가능성을 최소화하라 
규칙 16 계승하는 대신 구성하라 
규칙 17 계승을 위한 설계와 문서를 갖추거나, 그럴 수 없다면 계승을 금지하라 
규칙 18 추상 클래스 대신 인터페이스를 사용하라 
규칙 19 인터페이스는 자료형을 정의할 때만 사용하라 
규칙 20 태그 달린 클래스 대신 클래스 계층을 활용하라 
규칙 21 전략을 표현하고 싶을 때는 함수 객체를 사용하라 
규칙 22 멤버 클래스는 가능하면 static으로 선언하라 

5장 제네릭 

규칙 23 새 코드에는 무인자 제네릭 자료형을 사용하지 마라 
규칙 24 무점검 경고(unchecked warning)를 제거하라 
규칙 25 배열 대신 리스트를 써라 
규칙 26 가능하면 제네릭 자료형으로 만들 것 
규칙 27 가능하면 제네릭 메서드로 만들 것 
규칙 28 한정적 와일드카드를 써서 API 유연성을 높여라 
규칙 29 형 안전 다형성 컨테이너를 쓰면 어떨지 따져보라 

6장 열거형(enum)과 어노테이션 

규칙 30 int 상수 대신 enum을 사용하라 
규칙 31 ordinal 대신 객체 필드를 사용하라 
규칙 32 비트 필드(bit field) 대신 EnumSet을 사용하라 
규칙 33 ordinal을 배열 첨자로 사용하는 대신 EnumMap을 이용하라 
규칙 34 확장 가능한 enum을 만들어야 한다면 인터페이스를 이용하라 
규칙 35 작명 패턴 대신 어노테이션을 사용하라 
규칙 36 Override 어노테이션은 일관되게 사용하라 
규칙 37 자료형을 정의할 때 표식 인터페이스를 사용하라 

7장 메서드 

규칙 38 인자의 유효성을 검사하라 
규칙 39 필요하다면 방어적 복사본을 만들라 
규칙 40 메서드 시그너처는 신중하게 설계하라 
규칙 41 오버로딩할 때는 주의하라 
규칙 42 varargs는 신중히 사용하라 
규칙 43 null 대신 빈 배열이나 컬렉션을 반환하라 
규칙 44 모든 API 요소에 문서화 주석을 달라 

8장 일반적인 프로그래밍 원칙들 

규칙 45 지역 변수의 유효범위를 최소화하라 
규칙 46 for 문보다는 for-each 문을 사용하라 
규칙 47 어떤 라이브러리가 있는지 파악하고, 적절히 활용하라 
규칙 48 정확한 답이 필요하다면 float와 double은 피하라 
규칙 49 객체화된 기본 자료형 대신 기본 자료형을 이용하라 
규칙 50 다른 자료형이 적절하다면 문자열 사용은 피하라 
규칙 51 문자열 연결 시 성능에 주의하라 
규칙 52 객체를 참조할 때는 그 인터페이스를 사용하라 
규칙 53 리플렉션 대신 인터페이스를 이용하라 
규칙 54 네이티브 메서드는 신중하게 사용하라 
규칙 55 신중하게 최적화하라 
규칙 56 일반적으로 통용되는 작명 관습을 따르라 

9장 예외 327 

규칙 57 예외는 예외적 상황에만 사용하라 
규칙 58 복구 가능 상태에는 점검지정 예외를 사용하고, 프로그래밍 오류에는 실행시점 예외를 이용하라 
규칙 59 불필요한 점검지정 예외 사용은 피하라 
규칙 60 표준 예외를 사용하라 
규칙 61 추상화 수준에 맞는 예외를 던져라 
규칙 62 메서드에서 던져지는 모든 예외에 대해 문서를 남겨라 
규칙 63 어떤 오류인지를 드러내는 정보를 상세한 메시지에 담으라 
규칙 64 실패 원자성 달성을 위해 노력하라 
규칙 65 예외를 무시하지 마라 

10장 병행성 

규칙 66 변경 가능 공유 데이터에 대한 접근은 동기화하라 
규칙 67 과도한 동기화는 피하라 
규칙 68 스레드보다는 실행자와 태스크를 이용하라 
규칙 69 wait나 notify 대신 병행성 유틸리티를 이용하라 
규칙 70 스레드 안전성에 대해 문서로 남겨라 
규칙 71 초기화 지연은 신중하게 하라 
규칙 72 스레드 스케줄러에 의존하지 마라 
규칙 73 스레드 그룹은 피하라 

11장 직렬화 

규칙 74 Serializable 인터페이스를 구현할 때는 신중하라 
규칙 75 사용자 지정 직렬화 형식을 사용하면 좋을지 따져 보라 
규칙 76 readObject 메서드는 방어적으로 구현하라 
규칙 77 개체 통제가 필요하다면 readResolve 대신 enum 자료형을 이용하라 
규칙 78 직렬화된 객체 대신 직렬화 프락시를 고려해 보라

8장 프로그래밍 일반

규칙 45 지역 변수의 유효범위를 최소화하라

규칙 13 클래스와 멤버의 접근 권한을 최소화 하라와 유사
 지역 범위의 유효 범위를 최소화 하는 기법 -> **처음으로 사용하는 곳에 선언**

 블록 앞 부분에 선언하는 습관(C... Old language) -> 자료형, 초기값 잊어버리기 쉽다.  
 (while 보단 for loop)

 지역 변수 선언시에 초기값이 포함되어야 함.

 초기화하기에 충분한 정보가 없다면, 그때까지 선언을 미뤄야함.

 메소드의 크기를 줄이고 특정한 기능에 집중하라

 서로다른 두기능을 한 메소드에 넣으면, 한기능을 하는 지역 변수의 유효범위가 다른 기능까지 확장 될 수 있다. 
 -> 기능별로 나눠서 메소드를 만들어라.

규칙 46 for 문보다는 for-each 문을 사용하라

for-each가 1.5부터 도입됨  
for(Entity entity : entityList){}  
iterator 문제로 고생하고 싶지않다면 -> for-each

규칙 47 어떤 라이브러리가 있는지 파악하고, 적절히 활용하라

> 라이브러리 활용을 잘하자. 이미 검증 받고, 문제가 있더라도 고쳐진다.  
> 로직에 집중할 수 있게 해준다.  
> java.lang, java.util(collection, concurrency), java.io 내용은 어느정도 알고있어야한다.

규칙 48 정확한 답이 필요하다면 float와 double은 피하라

> 표현 범위때문에 생기는 문제가 있기때문에,

규칙 49 객체화된 기본 자료형 대신 기본 자료형을 이용하라

> 기본자료형(primitive type) int, double, boolean -> 값 그대로  
> 객체화된 기본 자료형(boxed primitive type) Integer, Double, Boolean -> 값과 신원(Identity) == 연산자를 사용하면 망함  
> 객체화된 기본 자료형이 NPE를 발생시킬 수 있음  
> 그래도 객체화된 기본 자료형을 써야하는 경우, ThreadLocal

규칙 50 다른 자료형이 적절하다면 문자열 사용은 피하라 ?

> 적합한 자료형이 있을때 적절한 자료형을 쓰자.

규칙 51 문자열 연결 시 성능에 주의하라

> n개의 문자열에 연결 연산자(+)를 반복 적용해서 연결하는데 드는시간 n^2 (비싸다)  
> 성능을 얻으려면, StringBuilder append

규칙 52 객체를 참조할 때는 그 인터페이스를 사용하라 ?

> java subscriber??

규칙 53 리플렉션 대신 인터페이스를 이용하라

~

규칙 54 네이티브 메서드는 신중하게 사용하라

> JNI(Java Native Interface) 를통해 성능을 개선하는 것은 추천하지 않음. JVM이 빠르기 때문, 필적하는 성능을 내는것이 가능하기도함.  
> 라이브러리의 최적화로 필적할만한 성능을 내도록 발전  
> JNI Platform Dependent함  
> 이식성 낮음

규칙 55 신중하게 최적화하라

> 섯부르게 최적화 하지말라..  
> 빠른 프로그램이 아닌 좋은 프로그램을 만드려 노력하라 ->좋은 프로그램은 정보의 은닉원칙을 지킨다. 설계에 관한 결정은 각 모듈 내부적으로 내려지고, 그 설계는 시스템의 영향을 주지 않으면서 독립적으로 변경 될 수 있다.

> 성능을 제약하는 문제가 시스템에 만연한 구조적 결함이라면 시스템 전부를 고치지 않고서는 문제를 해결하기 힘들다 (비싼 대가를 치뤄야함)

> 설계할 때는 성능을 제약 할 가능성이 있는 결정들은 피하자  
> API를 설계할 때 내리는 결정들이 성능에 어떤 영향을 끼칠지를 생각하라  
> 좋은 성능을 내기위해 API를 급진적으로 바꾸는 것은 바람직하지 않다.  
> 최적화를 한다면, "최적화를 시도할 때마다, 전후 성능을 측정하고 비교하라"  
> 일반적으로 프로그램 수행 시간 가운데 80% 정도는 20%가량의 코드를 수행하느라 소모된다.  
> 프로파일링 도구를 이용하면 어디를 최적화 할지 쉽게 결정 할 수 있다.  
> 처음으로 해야할일 -> 구현에 쓰인 알고리즘을 검토하는것

규칙 56 일반적으로 통용되는 작명 관습을 따르라

> naming convention -> ["The Java Language Specification"](https://docs.oracle.com/javase/specs/) -> 철자와 문법에 관한것  
> 패키지, 클래스, 인터페이스, 메서드, 필드, 자료형 변수

패키지  
표준라이브러리, 옵션 package -> java, javax -> 사용자면 쓰면 X  
인터넷 도메인을 패키지명 접두어로 변환하는 규칙

식별자 자료형 예제  
패키지: com.google.inject, org.joda.time.format  
클래스나 인터페이스: Timer, FutureTask, LinkedHashMap, HttpServlet  
메서드나 필드: remove, ensureCapacity, getCrc  
상수 필드: MIN\_VALUE, NEGATIVE\_INFINITY  
지역 변수: i, xref, houseNumber  
지료형 인자: 임의 자료형 T,컬렉션의 요소 자료형 E,맵의 키 K, 값 V,예외 X, T1, T2, T3

표준적 작명 관습을 내면화시키고 마치 제2의 천성인 것처럼 사용하라는 것이다. 철자 관습은 직관적이고 모호한 부분도 멸로 없다. 반면 문법적 관습은 좀 더 복잡하고 느슨하다.

관련글 더보기

댓글 영역

페이징