[이펙티브자바]ch67-ch71

67. 최적화는 신중히 하라

 

성능을 제한하는 설계를 피하라. 

외부 시스템과의 소통방식 (API, 네트워크 프롵토콜, 데이터 포맷등)을 신중히 설계하라. 

 

API를 설계할 때 성능에 주는 영향을 고려하라

- public 타입은 가변으로 만들지 말자. (방어적 복사를 매번 하도록 유발)

- 가능한 상속 대신 컴포지션을 사용하자. (나쁜 성능의 부모객체를 물려받는 것 방지)

- 구현 대신 이넡페이스를 사용하자. (더 빠른 구현체로 대체할 경우 대비)

 

최적화 전후로 성능을 측정하자. 

도구 예시 : jmh, 프로파일링 도구

 

68. 일반적으로 통용되는 명명 규칙을 따르라.

기본 문법

패키지와 모듈 : 각 요소를 점으로 구분. 

풀네임을 사용하자

Camel case 권장

상수는 대문자와 _의 조합으로 사용하기. 

 

복수형 vs 단수형

객체를 생성할 수 있는 클래스 : 단수 명사, 명사구

객체 생성 불가한 클래스: 복수형 명

 

인터페이스 이름

클래스와 같게, 혹은 형용사형으로

 

애너테이션

명명법 제한 x

 

특수 케이스

객체의 타입을 바꾼다: toType (예. toString)

객체의 값을 기본 타입 값으로 : typeValue (예. intValue)

정적팩터리: from, of, valueOf, instance, ...

 

명사형 메서드명

get 대신 명사형 메서드명을 쓰는 경우도 있다. 

예. car.speed() >= SPEED_LIMIT

 

69. 예외는 진짜 예외사항에만 사용하라.

예외 상황에서만 사용하고 일상적 제어 흐름용으로는 쓰지말자. 

1. 진짜 버그 발생시 원인 파악이 어렵다. 

2. 호출하는 클라이언트가 정상 제어흐름이라고 인식해야하는 불편함이 있다. 

 

만약 반복문을 종료해야한다면.  상태검사메서드를 사용하자.

(예. Iterator 인터페이스의 next와 hasNext)

 

70. 복구가능한 상황은 검사 예외, 프로그래밍 오류에는 런타임 예외를 사용하여라. 

throwable 종류

검사예외, 런타임 예외, 에러

 

검사 예외

- 호출하는 쪽에서 복구가능하다면 사용

- 예외 복구에 필요한 정보 함께 알려주자. 

 

비검사 throwable

(1) 런타임 예외

프로그래밍 오류  (전제조건을 만족하지 못했을 때. 예. indexOutOfBoundException)

(2)에러

 

사용하지 말아야할 throwable

Exception, RuntimeException, Error를 상속하지 않는 throwable 사용하지 말것 

 

예외에 대해서는 제대로 포맷팅하여 전달하자. 

파싱 없이 raw 데이터 그대로 전달하지 말것