[Java] 이펙티브 자바 - 9장(2/2), 10장(1/2) (아이템 64-72)

9장: 일반적인 프로그래밍 원칙

아이템 64. 객체는 인터페이스를 사용해 참조하라

인터페이스를 타입으로 사용하는 습관을 길러두면 프로그램이 훨씬 유연해질 수 있다. 나중에 구현 클래스를 교체하기 쉬움.

- 구현 타입을 바꾸려 하는 동기는? 새 구현 타입이 원래 것보다 성능이 좋거나 신기능을 제공...

적합한 인터페이스가 없다면 (당연히 클래스로 참조해야 하는 상황) -> 클래스의 계층구조 중 필요한 기능을 만족하는 가장 상위의 클래스를 타입으로 사용하자.

 

아이템 65. 리플렉션보다는 인터페이스를 사용하라

리플렉션 기능을 이용하면 프로그램에서 임의의 클래스에 접근 가능. 컴파일 당시 존재하지 않던 클래스도 이용할 수 있다.

- (단점: 컴파일타임 타입 검사 이점 누릴 수 x, 코드가 지저분하고 장황해짐, 성능 떨어짐)

리플렉션을 남용하면 x. 인스턴스 생성에만 쓰고, 이렇게 만든 인스턴스는 인터페이스나 상위 클래스로 참조해 사용하자.

- 생성한 객체 이용 시 적절한 인터페이스나 컴파일타임에 알 수 있는 상위 클래스로 형변환해 사용해야 한다.

 

아이템 66. 네이티브 메서드는 신중히 사용하라

성능을 개선할 목적으로 네이티브 메서드를 사용하는 것은 권장하지 않는다.

네이티브 언어가 안전하지 않으므로 메모리 훼손 오류로부터 안전하지 않다. 이식성 낮고, 디버깅 어렵고, 가비지 컬렉터가 네이티브 메로리를 자동 회수하지 못하고, 네이티브 메서드-자바 코드 사이 glue code를 작성해야만 함...

저수준 자원이나 네이티브 라이브러리를 사용해야만 해 어쩔 수 없더라도, 네이티브 코드는 최소한만 사용하고 철저히 테스트하라.

 

아이템 67. 최적화는 신중히 하라

마음에 새겨라.

"그 어떤 핑계보다 효율성이라는 이름 아래 행해진 컴퓨팅 죄악이 더 많다."

"자그마한 효율성은 모두 잊자. 섣부른 최적화가 만악의 근원이다."

"최적회를 할 때는 다음 두 규칙을 따르라. / 첫 번쨰, 하지 마라. / 두 번째, (전문가 한정) 아직 하지 마라. 다시 말해, 완전히 명백하고 최적화되지 않은 해법을 찾을 때까지는 하지 마라."

 

빠른 프로그램보다는 좋은 프로그램을 작성하라. 좋은 프로그램을 작성하다 보면 성능이 따라온다.

성능을 제한하는 설계를 피하는 것은 중요하다. (완성 후 변경하기 어려운 설계 요소들 만들 때-API, 네트워크 프로토콜, 영구 저장용 데이터 포맷)

- 특히, API를 설계할 때 성능에 주는 영향을 고려하라. public 타입을 가변으로 만들면 불필요한 방어적 복사를 수없이 유발할 수 있다.

 

"각각의 최적화 시도 전후로 성능을 추가하라."

- 프로파일링 도구 사용. 문제의 원인이 되는 지점 찾아 최적화하기.

 

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

자바 플랫폼은 명명 규칙이 잘 정립되어 있으며 그중 많은 것이 자바 언어 명세에 기술되어 있다.

철자, 문법

https://jjingho.tistory.com/117

10장: 예외

아이템 69. 예외는 진짜 예외 상황에만 사용하라

예외를 정상적인 제어 흐름에서 사용하면 안 된다.

잘 설계된 API라면 클라이언트가 정상적인 제어 흐름에서 예외를 사용할 일이 없게 해야 함.

- 상태 의존적 메서드를 제공하는 클래스는 상태 검사 메서드도 함께 제공해야 한다: Iterator 인터페이스의 next와 hasNext

- 만약 그렇지 않았다면 클라이언트가 예외처리를 해야 했을 것

 

아이템 70. 복구할 수 있는 상황에는 검사 예외를, 프로그래밍 오류에는 런타임 예외를 사용하라

언제 어떤 예외를 사용할까?

검사 예외: 호출하는 쪽에서 복구하리라 여겨지는 상황일 때

런타임 예외(비검사 예외): 프로그래밍 오류를 나타낼 때

- 개발자 구현 비검사 throwable은 모두 RuntimeException의 하위 클래스여야 한다.

아이템 71. 필요 없는 검사 예외 사용은 피하라

검사 예외

- 필요한 곳에 사용 시 장점: 프로그래밍의 안정성을 높여준다.

- 남용 시 단점: 호출하는 쪽에서 붙잡아 처리하거나 더 바깥으로 던져야 하므로 API 사용자에게 부담을 준다.

 

언제 무슨 예외를 던지지?

- API 호출자가 예외 상황에서 복구할 방법이 없다면 (검사 예외 말고) 비검사 예외를 던지자.

 

- 복구가 가능하고 호출자가 처리를 해주길 바란다면, 우선 적절한 결과 타입을 담은 빈 Optional을 반환해도 될지 고민하자.

  - Optional 반환 시 단점: 예외가 발생한 이유를 알려주는 부가 정보를 담을 수 없다.

- 검사 예외를 던지는 메서드를 쪼개어서 비검사 예외로 바꾸는 리팩토링도 수행할 수 있다. (모든상황에 적용은 불가)

 

- Optional만으로 상황을 처리하기에 충분한 정보를 제공할 수 없을 때 검사 예외를 던지자.

아이템 72. 표준 예외를 사용하라

Exception, RuntimeException, Throwable, Error는 직접 재사용하지 말자.

여러 성격의 예외들의 상위 클래스이므로 안정적으로 테스트할 수 없다.

상황에 부합한다면 항상 표준 예외를 재사용하자. 

더 많은 정보를 제공하기 원한다면 표준 예외를 확장해도 좋다. 단, 예외는 직렬화할 수 있다는 사실을 기억하자.