[冊] 이펙티브 자바

2장 객체 생성과 파괴 아이템 1. 생성자 대신 정적 팩터리 메서드를 고려하라 클래스는 클라이언트에 public 생성자 대신 (혹은 생성자와 함께) 정적 팩터리 메서드를 제공할 수 있다. 이 방식에는 장점과 단점이 모두 존재한다. 먼저 정적 팩터리 메서드가 생성자보다 좋은 장점 다섯 가지를 알아 보자. 첫 번째, 이름을 가질 수 있다. 생성자에 넘기는 매개변수와 생성자 자체만으로는 반환될 객체의 특성을 제대로 설명하지 못한다. 반면 정적 팩터리는 이름만 잘 지으면 반환될 객체의 특성을 쉽게 묘사할 수 있다. 예컨대 생성자인 BigInteger(int, int, Random)과 정적 팩터리 메서드인 BigInteger.probablePrime 중 어느 쪽이 ‘값이 소수인 BigInteger를 반환한다’는 의미를 잘 설명할 것 같은지 생각해 보라. (BigInteger.probablePrime은 자바 4에서 추가됐다.) 하나의 시그니처로는 생성자 하나만 만들 수 있다. 입력 매개변수들의 순서를 다르게 한 생성자는 새로 추가하는 식으로 이 제한을 피해볼 수도 있지만, 좋지 않은 발상이다. 그런 API를 사용하는 개발자는 각 생성자가 어떤 역할을 하는지 정확히 기억하기 어려워 엉뚱한 것을 호출하는 실수를 할 수 있다. 코드를 읽는 사람도 클래스 설명 문서를 찾아보지 않고는 의미를 알지 못할 것이다. 이름을 가질 수 있는 정적 팩터리 메서드에는 이런 제약이 없다. 한 클래스에 시그니처가 같은 생성자가 여러 개 필요할 것 같으면, 생성자를 정적 팩터리 메서드로 바꾸고 각각의 차이를 잘 드러내는 이름을 지어주자. 두 번째, 호출될 때마다 인스턴스를 새로 생성하지는 않아도 된다. 이 덕분에 불변 클래스는 인스턴스를 미리 만들어 놓거나 새로 생성한 인스턴스를 캐싱하여 재활용하는 식으로 불필요한 객체 생성을 피할 수 있다. 대표적 예은 Boolean.valueOf(boolean) 메서드는 객체를 아예 생성하지 않는다. 따라서 (특히 생성 비용이 큰) 같은 객체가 자주 요청되는 상황이라면 성능을 상당히 끌어올려 준다. 플라이웨이트 패턴도 이와 비슷한 기법이라 할 수 있다. 반복되는 요청에 같은 객체를 반환하는 식으로 정적 팩터리 방식의 클래스는 언제 어느 인스턴스를 살아 있게 할지를 철저히 통제할 수 있다. 이런 클래스를 인스턴스 통제 클래스하고 한다. 그렇다면 인스턴스를 통제하는 이유는 무엇일까? 인스턴스를 통제하면 클래스를 싱글턴으로 만들 수도, 인스턴스화 불가로 만들수도 있다. 또한 불편 값 클래스에서 동작인 인스턴스가 단 하나뿐임을 보장할 수 있다. 인스턴스 통제는 플라이웨이트 패턴의 근간이 되며, 열거 타입은 인스턴스가 하나만 만들어짐을 보장한다. 세 번째, 반환 타입의 하위 타입을 객체를 반환할 수 있는 능력이 있다. 이 능력은 반환할 객체의 클래스를 자유롭게 선택할 수 있게 하는 ‘엄청난 유연성’을 선물한다. API를 만들 때 이 유연성을 응용하면 구현 클래스를 공개하지 않고도 그 객체를 봔환할 수 있어 API를 작게 유지할 수 있다. 이는 인터페이스를 정적 팩터리 메서드의 반환 타입으로 사용하는 인터페이스 기반 프레임워크를 만드는 핵심 기술이기도 하다. 자바 8 전에는 인터페이스에 정적 메서드를 선언할 수 없었다. 그렇기 때문에 이름이 “Type”인 인터페이슬르 반환하는 정적 메서드가 필요하면, “Types”라는 동반 클래스를 만들어 그 안에 정의한느 것이 관례였다. 예컨대 자바 컬렉션 프레임워크는 핵심 인터페이스들에 수정 불가나 동기화 등의 기능을 덧붙인 총 45개 클래스를 공개하지 않기 때문에 API 외견을 훨씬 작게 만들 수 있었다. API가 작아진 것은 물론 개념적인 무게, 즉 프로그래머가 API를 사용하기 위해 익혀야하는 개념의 수와 난이도를 낮췄다. 프로그래머는 명시한 인터페이스대로 동작하는 객체를 얻을 것임을 알기에 굳이 별도 문서를 찾아가며 실제 구현 클래스가 무엇인지 알아보지 않아도 된다. 나아가 정적 팩터리 메서드를 사용하는 클라이언트는 얻은 객체를 인터페이스만으로 다루게 된다. 이는 일반적으로 좋은 습관이다. 자바 8부터는 인터페이스가 정적 메서드를 가질 수 없다는 제한이 풀렸기 때문에 인스턴스화 불가 동반 클래스를 둘 이유가 별로 없다. 동반 클래스에 두었던 public 정적 멤버들 상당 수를 그냥 인터페이스 자체에 두면 되는 것이다. 하지만 정적 메서드들을 구현하기 위한 코드 중 많은 부분은 여전히 별도의 package-private 클래스에 두어야 할 수 있다. 자바 8에서도 인터페이스에는 public 정적 메서드까지 허락하지만 정적 필드와 정적 멤버 클래스는 여전히 public 이어야 한다. 네 번째, 입력 매개변수에 따라 매번 다른 클래스의 객체를 반환할 수 있다. 반환 타입의 하위 타입이기만 하면 어떤 클래스의 객체를 반환하든 상관 없다. 심지어 다음 릴리스에서는 또 다른 클래스의 객체를 반환해도 된다. 가령 EnumSet 클래스는 public 생성자 없이 오직 정적 팩터리만 제공하는데, OpenJDK에서는 원소의 수에 따라 두 가지 하위 클래스 중 하나의 인스턴스를 반환한다. (대다수에 해당하는) 원소가 64개 이하면 원소들을 long 변수 하나로 관리하는 RegularEnumSet의 인스턴스를 반환한다. 클라이언트는 이 두 클래스의 존재를 모른다. 만약 원소가 적을 때 RegularEnumSet을 사용할 이점이 없어진다면 다음 릴리스 때는 이를 삭제해도 아무 문제가 없다. 비슷하게, 성능을 더 개선한 세 번째, 네 번째 클래스를 다음 릴리스에 추가할 수도 있다. 클라이언트는 팩터리가 건네주는 객체가 어느 클래스의 인스턴스인지 알 수도 없고 알 필요도 없다. EnumSet의 하위 클래스 이기만 하면 되는 것이다. 다섯 번째, 정적 팩터리 메서드를 작성하는 시점에는 반환할 객체의 클래스가 존재하지 않아도 된다. 이런 유연함은 서비스 제공자 프레임워크를 만드는 근간이 된다. 대표적인 서비스 제공자 프레임워크로는 JDBC가 있다. 서비스 제공자 프레임워크에서의 제공자는 서비스의 구현체이다. 그리고 이 구현체들을 클라이언트에 제공하는 역할을 프레임워크가 통제하여, 클라이언트를 구현체로부터 분리해준다. 서비스 제공자 프레임워크는 3개의 핵심 컴포넌트로 이뤄진다. 구현체의 동작을 정의하는 서비스 인터페이스, 제공자가 구현체를 등록할 때 사용하는 제공자 등록 API, 클라이언트가 서비스의 인스턴스를 얻을 때 사용하는 서비스 접근 API를 사용할 때, 원하는 구현체의 조건을 명시할 수 있다. 조건을 명시하지 않으면 기본 구현체를 반환하거나 지원하는 구현체들을 하나씩 돌아가며 반환한다. 이 서비스 접근 API가 바로 서비스 제공자 프레임워크의 근간이라고 한 ‘유연한 정적 팩터리’의 실체이다. 3개의 핵심 컴포넌트와 더불어 종종 서비스 제공자 인터페이스라는 네 번째 컴포넌트가 쓰이기도 한다. 이 컴포넌트는 서비스 인터페이스의 인스턴스를 생성하는 팩터리 객체를 설명해준다. 서비스 제공자 인터페이스가 없다면 각 구현체를 인스턴스로 만들 때 리플렉션을 사용해야 한다. JDBC에서는 connection이 서비스 인터페이스 역할을, DriverManager, registerDriver가 제공자 등록 API 역활을, DriverManager.getConnection이 서비스 접근 API 역할을, Driver가 서비스 제공자 인터페이스 역할을 수행한다. 서비스 제공자 프레임워크 패턴에는 여러 변형이 있다. 예컨대 서비스 접근 API는 공급자가 제공하는 것보다 더 풍부한 서비스 인터페이스를 클라이언트에 반환할 수 있다. 브리지 패턴이라 알려진 것이다. 의존 객체 주입 프레임워크도 강력한 서비스 제공자라고 생각할 수 있다. 자바 5부터는 java.util.ServiceLoader라는 범용 서빗 제공자 프레임워크가 제공되어 프레임워크를 직접 만들 필요가 거의 없어졌다. 한편, JDBC는 자바 5 전에 등장한 개념이라 ServiceLoader를 사용하지 않는다.

[冊] 이펙티브 자바 : 목차

목차

1장 들어가기

2장 객체 생성과 파괴

아이템 1. 생성자 대신 정적 팩터리 메서드를 고려하라

아이템 2. 생성자에 매개변수가 많다면 빌더를 고려하라

아이템 3. private 생성자나 열거 타입으로 싱글턴임을 보증하라

아이템 4. 인스턴스화를 막으려거든 private 생성자를 사용하라

아이템 5. 자원을 직접 명시하지 말고 의존 객체 주입을 사용하라

아이템 6. 불필요한 객체 생성을 피하라

아이템 7. 다 쓴 객체 참조를 해제하라

아이템 8. finalizer와 cleaner 사용을 피하라

아이템 9. try-finally보다는 try-with-resources를 사용하라

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

아이템 10. equals는 일반 규약을 지켜 재정의하라

아이템 11. equals를 재정의하려거든 hashCode도 재정의하라

아이템 12. toString을 항상 재정의하라

아이템 13. clone 재정의는 주의해서 진행하라

아이템 14. Comparable을 구현할지 고려하라

4장 클래스와 인터페이스

아이템 15. 클래스와 멤버의 접근 권한을 최소화하라

아이템 16. public 클래스에서는 public 필드가 아닌 접근자 메서드를 사용하라

아이템 17. 변경 가능성을 최소화하라

아이템 18. 상속보다는 컴포지션을 사용하라

아이템 19. 상속을 고려해 설계하고 문서화하라. 그러지 않았다면 상속을 금지하라

아이템 20. 추상 클래스보다는 인터페이스를 우선하라

아이템 21. 인터페이스는 구현하는 쪽을 생각해 설계하라

아이템 22. 인터페이스는 타입을 정의하는 용도로만 사용하라

아이템 23. 태그 달린 클래스보다는 클래스 계층구조를 활용하라

아이템 24. 멤버 클래스는 되도록 static으로 만들라

아이템 25. 톱레벨 클래스는 한 파일에 하나만 담으라

5장 제네릭

아이템 26. 로 타입은 사용하지 말라

아이템 27. 비검사 경고를 제거하라

아이템 28. 배열보다는 리스트를 사용하라

아이템 29. 이왕이면 제네릭 타입으로 만들라

아이템 30. 이왕이면 제네릭 메서드로 만들라

아이템 31. 한정적 와일드카드를 사용해 API 유연성을 높이라

아이템 32. 제네릭과 가변인수를 함께 쓸 때는 신중하라

아이템 33. 타입 안전 이종 컨테이너를 고려하라

6장 열거 타입과 애너테이션

아이템 34. int 상수 대신 열거 타입을 사용하라

아이템 35. ordinal 메서드 대신 인스턴스 필드를 사용하라

아이템 36. 비트 필드 대신 EnumSet을 사용하라

아이템 37. ordinal 인덱싱 대신 EnumMap을 사용하라

아이템 38. 확장할 수 있는 열거 타입이 필요하면 인터페이스를 사용하라

아이템 39. 명명 패턴보다 애너테이션을 사용하라

아이템 40. @Override 애너테이션을 일관되게 사용하라

아이템 41. 정의하려는 것이 타입이라면 마커 인터페이스를 사용하라

7장 람다와 스트림

아이템 42. 익명 클래스보다는 람다를 사용하라

아이템 43. 람다보다는 메서드 참조를 사용하라

아이템 44. 표준 함수형 인터페이스를 사용하라

아이템 45. 스트림은 주의해서 사용하라

아이템 46. 스트림에서는 부작용 없는 함수를 사용하라

아이템 47. 반환 타입으로는 스트림보다 컬렉션이 낫다

아이템 48. 스트림 병렬화는 주의해서 적용하라

8장 메서드

아이템 49. 매개변수가 유효한지 검사하라

아이템 50. 적시에 방어적 복사본을 만들라

아이템 51. 메서드 시그니처를 신중히 설계하라

아이템 52. 다중정의는 신중히 사용하라

아이템 53. 가변인수는 신중히 사용하라

아이템 54. null이 아닌, 빈 컬렉션이나 배열을 반환하라

아이템 55. 옵셔널 반환은 신중히 하라

아이템 56. 공개된 API 요소에는 항상 문서화 주석을 작성하라

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

아이템 57. 지역변수의 범위를 최소화하라

아이템 58. 전통적인 for 문보다는 for-each 문을 사용하라

아이템 59. 라이브러리를 익히고 사용하라

아이템 60. 정확한 답이 필요하다면 float와 double은 피하라

아이템 61. 박싱된 기본 타입보다는 기본 타입을 사용하라

아이템 62. 다른 타입이 적절하다면 문자열 사용을 피하라

아이템 63. 문자열 연결은 느리니 주의하라

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

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

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

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

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

10장 예외

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

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

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

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

아이템 73. 추상화 수준에 맞는 예외를 던지라

아이템 74. 메서드가 던지는 모든 예외를 문서화하라

아이템 75. 예외의 상세 메시지에 실패 관련 정보를 담으라

아이템 76. 가능한 한 실패 원자적으로 만들라

아이템 77. 예외를 무시하지 말라

11장 동시성

아이템 78. 공유 중인 가변 데이터는 동기화해 사용하라

아이템 79. 과도한 동기화는 피하라

아이템 80. 스레드보다는 실행자, 태스크, 스트림을 애용하라

아이템 81. wait와 notify보다는 동시성 유틸리티를 애용하라

아이템 82. 스레드 안전성 수준을 문서화하라

아이템 83. 지연 초기화는 신중히 사용하라

아이템 84. 프로그램의 동작을 스레드 스케줄러에 기대지 말라

12장 직렬화

아이템 85. 자바 직렬화의 대안을 찾으라

아이템 86. Serializable을 구현할지는 신중히 결정하라

아이템 87. 커스텀 직렬화 형태를 고려해보라

아이템 88. readObject 메서드는 방어적으로 작성하라

아이템 89. 인스턴스 수를 통제해야 한다면 readResolve보다는 열거 타입을 사용하라

아이템 90. 직렬화된 인스턴스 대신 직렬화 프록시 사용을 검토하라