├── README.md
├── chap02
    ├── Item1.md
    ├── Item2.md
    ├── Item3.md
    ├── Item4.md
    ├── Item5.md
    ├── Item6.md
    ├── Item7.md
    ├── Item8.md
    └── Item9.md
├── chap03
    ├── Item10.md
    ├── Item11.md
    ├── Item12.md
    ├── Item13.md
    └── Item14.md
├── chap04
    ├── Item15.md
    ├── Item16.md
    ├── Item17.md
    ├── Item18.md
    ├── Item19.md
    ├── Item20.md
    ├── Item21.md
    ├── Item22.md
    ├── Item23.md
    ├── Item24.md
    └── Item25.md
├── chap05
    ├── Item26.md
    ├── Item27.md
    ├── Item28.md
    ├── Item29.md
    ├── Item30.md
    ├── Item31.md
    ├── Item32.md
    └── Item33.md
├── chap06
    ├── Item34.md
    ├── Item35.md
    ├── Item36.md
    ├── Item37.md
    ├── Item38.md
    ├── Item39.md
    ├── Item40.md
    └── Item41.md
├── chap07
    ├── Item42.md
    ├── Item43.md
    ├── Item44.md
    ├── Item45.md
    ├── Item46.md
    ├── Item47.md
    └── Item48.md
├── chap08
    ├── Item49.md
    ├── Item50.md
    ├── Item51.md
    ├── Item52.md
    ├── Item53.md
    ├── Item54.md
    ├── Item55.md
    └── Item56.md
├── chap09
    ├── Item57.md
    ├── Item58.md
    ├── Item59.md
    ├── Item60.md
    ├── Item61.md
    ├── Item62.md
    ├── Item63.md
    ├── Item64.md
    ├── Item65.md
    ├── Item66.md
    ├── Item67.md
    └── Item68.md
├── chap10
    ├── Item69.md
    ├── Item70.md
    ├── Item71.md
    ├── Item72.md
    ├── Item73.md
    ├── Item74.md
    ├── Item75.md
    ├── Item76.md
    └── Item77.md
├── chap11
    ├── Item78.md
    ├── Item79.md
    ├── Item80.md
    ├── Item81.md
    ├── Item82.md
    ├── Item83.md
    └── Item84.md
└── chap12
    ├── Item85.md
    ├── Item86.md
    ├── Item87.md
    ├── Item88.md
    ├── Item89.md
    └── Item90.md


/README.md:
--------------------------------------------------------------------------------
 1 | # Effective-java 3/E 요약
 2 | ### Effective Java 3/E 학습하면서 정리한 내용입니다.
 3 | ---
 4 | ###  **chap02**
 5 | - [[Item 1] 생성자 대신 정적 팩토리 메서드를 고려하라](https://github.com/brick0123/effective-java/blob/main/chap02/Item1.md)
 6 | - [[Item 2] 생성자에 매개변수가 많다면 빌더를 고려하라](https://github.com/brick0123/effective-java/blob/main/chap02/Item2.md)
 7 | - [[Item 3] private 생성자나 열거 타입으로 싱글턴임을 보증하라](https://github.com/brick0123/effective-java/blob/main/chap02/Item3.md)
 8 | - [[Item 4] 인스턴스화를 막으려거든 private 생성자를 사용하라인스턴스화를 막으려거든 private 생성자를 사용하라](https://github.com/brick0123/effective-java/blob/main/chap02/Item4.md)
 9 | - [[Item 5] 자원을 직접 명시하지 말고 의존 객체 주입을 사용하라](https://github.com/brick0123/effective-java/blob/main/chap02/Item5.md)
10 | - [[Item 6] 불필요한 객체 생성을 피하라](https://github.com/brick0123/effective-java/blob/main/chap02/Item6.md)
11 | - [[Item 7] 다 쓴 객체 참조를 해제하라](https://github.com/brick0123/effective-java/blob/main/chap02/Item7.md)
12 | - [[Item 8]finalizer와 cleaner 사용을 피하라](https://github.com/brick0123/effective-java/blob/main/chap02/Item8.md)
13 | - [[Item 9] try-finally보다는 try-with-resources를 사용하라](https://github.com/brick0123/effective-java/blob/main/chap02/Item2.md)
14 | 
15 | ### **chap03**
16 | - [[Item 10] equals는 일반 규약을 지켜 재정의하라](https://github.com/brick0123/effective-java/blob/main/chap03/Item10.md)
17 | - [[Item 11] equals를 재정의하려거든 hashCode도 재정의하라](https://github.com/brick0123/effective-java/blob/main/chap03/Item11.md)
18 | - [[Item 12] toString을 항상 재정의하라](https://github.com/brick0123/effective-java/blob/main/chap03/Item12.md)
19 | - [[Item 13] clone 재정의는 주의해서 진행하라](https://github.com/brick0123/effective-java/blob/main/chap03/Item13.md)
20 | - [[Item 14] Comparable을 구현할지 고려하라](https://github.com/brick0123/effective-java/blob/main/chap03/Item14.md)
21 | 
22 | ## **chap04**
23 | - [[Item 15] 클래스와 멤버의 접근 권한을 최소화하라](https://github.com/brick0123/effective-java/blob/main/chap04/Item15.md)
24 | - [[Item 16] public 클래스에서는 public 필드가 아닌 접근자 메서드를 사용하라](https://github.com/brick0123/effective-java/blob/main/chap04/Item16.md)
25 | - [[Item 17] 변경 가능성을 최소화하라](https://github.com/brick0123/effective-java/blob/main/chap04/Item17.md)
26 | - [[Item 18] 상속보다는 컴포지션을 사용하라](https://github.com/brick0123/effective-java/blob/main/chap04/Item18.md)
27 | - [[Item 19] 상속을 고려해 설계하고 문서화하라. 그러지 않았다면 상속을 금지하라](https://github.com/brick0123/effective-java/blob/main/chap04/Item19.md)
28 | - [[Item 20] 추상 클래스보다는 인터페이스를 우선하라](https://github.com/brick0123/effective-java/blob/main/chap04/Item20.md)
29 | - [[Item 21] 인터페이스는 구현하는 쪽을 생각해 설계하라](https://github.com/brick0123/effective-java/blob/main/chap04/Item21.md)
30 | - [[Item 22] 인터페이스는 타입을 정의하는 용도로만 사용하라](https://github.com/brick0123/effective-java/blob/main/chap04/Item22.md)
31 | - [[Item 23] 태그 달린 클래스보다는 클래스 계층구조를 활용하라](https://github.com/brick0123/effective-java/blob/main/chap04/Item23.md)
32 | - [[Item 24] 멤버 클래스는 되도록 static으로 만들라](https://github.com/brick0123/effective-java/blob/main/chap04/Item24.md)
33 | - [[Item 25] 톱레벨 클래스는 한 파일에 하나만 담으라](https://github.com/brick0123/effective-java/blob/main/chap04/Item25.md)
34 | 
35 | ## **chap05**
36 | - [[Item 26] 로 타입은 사용하지 말라](https://github.com/brick0123/effective-java/blob/main/chap05/Item26.md)
37 | - [[Item 27] 비검사 경고를 제거하라](https://github.com/brick0123/effective-java/blob/main/chap05/Item27.md)
38 | - [[Item 28] 배열보다는 리스트를 사용하라](https://github.com/brick0123/effective-java/blob/main/chap05/Item28.md)
39 | - [[Item 29] 이왕이면 제네릭 타입으로 만들라](https://github.com/brick0123/effective-java/blob/main/chap05/Item29.md)
40 | - [[Item 30] 이왕이면 제네릭 메서드로 만들라](https://github.com/brick0123/effective-java/blob/main/chap05/Item30.md)
41 | - [[Item 31] 한정적 와일드카드를 사용해 API 유연성을 높이라](https://github.com/brick0123/effective-java/blob/main/chap05/Item31.md)
42 | - [[Item 32] 제네릭과 가변인수를 함께 쓸 때는 신중하라](https://github.com/brick0123/effective-java/blob/main/chap05/Item32.md)
43 | - [[Item 33] 타입 안전 이종 컨테이너를 고려하라](https://github.com/brick0123/effective-java/blob/main/chap05/Item33.md)
44 | 
45 | ## **chap06**
46 | - [[Item 34] int 상수 대신 열거 타입을 사용하라](https://github.com/brick0123/effective-java/blob/main/chap06/Item34.md)
47 | - [[Item 35] ordinal 메서드 대신 인스턴스 필드를 사용하라](https://github.com/brick0123/effective-java/blob/main/chap06/Item35.md)
48 | - [[Item 36] 비트 필드 대신 EnumSet을 사용하라](https://github.com/brick0123/effective-java/blob/main/chap06/Item36.md)
49 | - [[Item 37] ordinal 인덱싱 대신 EnumMap을 사용하라](https://github.com/brick0123/effective-java/blob/main/chap06/Item37.md)
50 | - [[Item 38] 확장할 수 있는 열거 타입이 필요하면 인터페이스를 사용하라](https://github.com/brick0123/effective-java/blob/main/chap06/Item38.md)
51 | - [[Item 39] 명명 패턴보다 애너테이션을 사용하라](https://github.com/brick0123/effective-java/blob/main/chap06/Item39.md)
52 | - [[Item 40] @Override 애너테이션을 일관되게 사용하라](https://github.com/brick0123/effective-java/blob/main/chap06/Item40.md)
53 | - [[Item 41] 정의하려는 것이 타입이라면 마커 인터페이스를 사용하라](https://github.com/brick0123/effective-java/blob/main/chap06/Item41.md)
54 | 
55 | ## **chap07**
56 | - [[Item 42] 매개변수가 유효한지 검사하라](https://github.com/brick0123/effective-java/blob/main/chap07/Item42.md)
57 | - [[Item 43] 매개변수가 유효한지 검사하라](https://github.com/brick0123/effective-java/blob/main/chap07/Item43.md)
58 | - [[Item 44] 매개변수가 유효한지 검사하라](https://github.com/brick0123/effective-java/blob/main/chap07/Item44.md)
59 | - [[Item 45] 매개변수가 유효한지 검사하라](https://github.com/brick0123/effective-java/blob/main/chap07/Item45.md)
60 | - [[Item 46] 매개변수가 유효한지 검사하라](https://github.com/brick0123/effective-java/blob/main/chap07/Item46.md)
61 | - [[Item 47] 매개변수가 유효한지 검사하라](https://github.com/brick0123/effective-java/blob/main/chap07/Item47.md)
62 | - [[Item 48] 매개변수가 유효한지 검사하라](https://github.com/brick0123/effective-java/blob/main/chap07/Item48.md)
63 | 
64 | ## **chap08**
65 | - [[Item 49] 매개변수가 유효한지 검사하라](https://github.com/brick0123/effective-java/blob/main/chap08/Item49.md)
66 | - [[Item 51] 적시에 방어적 복사본을 만들라](https://github.com/brick0123/effective-java/blob/main/chap08/Item50.md)
67 | - [[Item 52] 다중정의는 신중히 사용하라](https://github.com/brick0123/effective-java/blob/main/chap08/Item50.md)
68 | - [[Item 53] 가변인수는 신중히 사용하라](https://github.com/brick0123/effective-java/blob/main/chap08/Item50.md)
69 | - [[Item 54] null이 아닌, 빈 컬렉션이나 배열을 반환하라](https://github.com/brick0123/effective-java/blob/main/chap08/Item50.md)
70 | - [[Item 55] 옵셔널 반환은 신중히 하라](https://github.com/brick0123/effective-java/blob/main/chap08/Item50.md)
71 | - [[Item 56] 공개된 API 요소에는 항상 문서화 주석을 작성하라](https://github.com/brick0123/effective-java/blob/main/chap08/Item50.md)
72 | 
73 | 
74 | 
75 | 
76 | 
77 | 


--------------------------------------------------------------------------------
/chap02/Item1.md:
--------------------------------------------------------------------------------
 1 | # [Iteam 1] 생성자 대신 정적 팩토리 메서드를 고려하라
 2 | 
 3 | ### 일반적으로 사용하는 public 생성자 대신,  별도로 **정적 팩토리 메소드**를 이용할 수 있다.
 4 | </br>
 5 | Boolean 클래스에서 발췌한 예제 코드</br>
 6 | 
 7 | ``` java
 8 | public static Boolean valueOf(boolean b) {
 9 |     return b ? Boolean.TRUE : Booelan.FALSE;
10 | }
11 | ```
12 | 
13 | ## **장점**
14 | ### **1. 이름을 가질 수 있다.**</br>
15 | 생성자에 넘기는 매개변수만으로 반활된 객체의 특성을 제대로 설명하지 못합니다.</br>
16 | 반면 정적 팩터리 메서드는 이름을 잘 지으면 반환될 객체의 특성을 쉽게 묘사할 수 있습니다.</br>
17 | 하나의 시그니처로는 생성자를 하나만 만들 수 있으며 입력 매개변수들의 순서를 다르게 한 생성자를 추가하는 식으로 이 제한을 피할 수는 있지만,이 역시 객체의 특성을 살리기 힘들고 좋지 않은 방식입니다.</br>
18 | 정적 팩토리 메소드는 이러한 제약이 없으며 시그니처가 같은 생성자가 여러 개 필요할 거 같으면</br>
19 | 생성자를 정적 팩터리 메서드로 바꾸고 각각의 차이를 잘 드러내는 이름을 지어내는 방법을 사용할 수 있습니다.
20 | </br></br>
21 | 
22 | ### **2. 호출될 때마다 인스턴스를 새로 생성하지 않아도 된다.**</br>
23 | 불변 클래스(immutable class)는 미리 만들어 놓거나 새로 생성한 인스턴스를 캐싱하여 재활용하는 식으로 불필요한 객체 생성을 피할 수 있습니다. 따라서 객체가 자주 요청되는 상황이라면 성능을 상당히 끌어 올릴 수 있습니다.`Boolean.valueOf(boolean)` 메소드도 그 경우에 해당됩니다.
24 | 
25 | ### **3. 반환 타입의 하위 타입 객체를 반환할 수 있는 능력이 있다.**</br>
26 | 반환할 객체의 클래스를 선택할 수 있는 유연함이 있습니다. 리턴 타입의 하위 타입의 인스턴스를 반환할 수 있으므로 가능합니다. API를 만들때 유연성을 이용하여 구현 클래스를 공개하지 않고도 그 객체를 반환할 수 있어 API를 작게 유지할 수 있습니다.</br></br>
27 | 자바 컬렉션 프레임워크는 핵심 인터페이스들에 수정 불가나 동기화 등의 기능을 덧붙인</br>
28 | 총 45개의 유틸리티구현체를 제공하는데, 이 구현체는 대부분 단 하나의 인스턴스화 불가 클래스인`java.util.Collections`에서 정적 팩터리 메소드를 통해 얻도록 했습니다.</br></br>
29 | 컬렉션 프레임워크는 이 45개의 클래스를 공개하지 않기 때문에 API의 외견을 훨씬 작게 만들 수 있었습니다.</br>
30 | 여기서 무게는 프로그래머가 API를 사용하기 위해 익혀야하는 개념의 수와 난이도를 맗합니다.</br>
31 | 클라이언트가 구현체가 아닌 인터페이스를 다루게 되므로 역할과 구현이 나눠지므로 결합도가 낮출 수 있습니다.</br></br>
32 | ### **4.입력 매개변수에 따라 매번 다른 클래스의 객체를 반환할 수 있다.**</br>
33 | 장점 3에서 말했듯이 하위 타입이기만 하면 어떤 클래스의 객체를 반환하던 상관 없습니다.</br>
34 | 가령 EumSet 클래스는 public 생성자 없이 오직 정적 펙토리 메서드만 제공합니다. `nonOf` 등..</br>nonOf 메서드를 살펴보면 원소 수에 따라 `RegularEnumSet`이나  `JumbEnumSet`인스턴스를 반환 합니다.</br>
35 | ``` java
36 |     public static <E extends Enum<E>> EnumSet<E> noneOf(Class<E> elementType) {
37 |         Enum<?>[] universe = getUniverse(elementType);
38 |         if (universe == null)
39 |             throw new ClassCastException(elementType + " not an enum");
40 | 
41 |         if (universe.length <= 64)
42 |             return new RegularEnumSet<>(elementType, universe);
43 |         else
44 |             return new JumboEnumSet<>(elementType, universe);
45 |     }
46 | 
47 | ```
48 | </br></br>
49 | ### **5.정적 팩토리 메서드를 작성하는 시점에는 반환할 객체의 클래스가 존재하지 않아도 된다.**
50 | 대표적인 프레워크로는 JDBC가 있습니다. 구현체들은 클라이언트에 제공하는 역할을 프레임워크가 통제하여, 클라이언트를 구현체로부터 분리해줍니다.</br>
51 | 
52 | 서비스 제공자 프레임워크는 3개의 핵심 컴포넌트로 이루어집니다. (제공자는 서비스의 구현체를 의미합니다)</br>
53 | - 서비스 인터페이스 (구현체의 동작을 정의)
54 | - 제공자 등록 API  (제공자가 구현체를 등록할 때 사용)
55 | - 서비스 접근 API  (클라이언트가 서비스의 인스터스를 얻을 때 사용)
56 | 
57 | 서비스 접근 API를 사용할 때 원하는 구현체의 조건을 명시할 수 있습니다. 조건을 명시하지 않으면 기본 구현체를 반화하거나 지원하는 구현체들을 하나씩 돌아가면서 반환합니다.
58 | 
59 | ## **단점**
60 | ### **1.상속을 하려면 public이나 protected 생성자가 필요하니 정적 팩토리 메서드만 제공하면 하위 클래스를 만들 수 없다**
61 | 이 제약은 상속보다(is a) 컴포지션을(has) 사용하도록 유도하고 불변 타입으로 만들려면 이 제약을 지켜야 한다는 점에서 오히려 장점으로 받아들일 수도 있습니다.
62 | </br></br>
63 | 
64 | ### **2.정적 팩토리 메서드는 프로그래머가 찾기 어렵다.**
65 | 생성자처럼 API설명에 명확히 드러나지 않으므로 사용자는 정적 팩토리 메서드 사용 방식 클래스를 인스턴스화 시킬 방법을 알아내야 합니다. 그러므로 API 문서를 잘 정리하고 메서드 이름도 널리 알려진 규약을 따르는 게 좋습니다.
66 | 
67 | 
68 | 
69 |    
70 | 


--------------------------------------------------------------------------------
/chap02/Item2.md:
--------------------------------------------------------------------------------
  1 | # [Item 2] 생성자에 매개변수가 많다면 빌더를 고려해라.
  2 | </br>
  3 | 매개변수가 많아질 경우 정적 팩토리 메서드와 생성자는 사용하기 불편해집니다. </br></br>
  4 | 
  5 | ### **첫번째 대안: 생성자를 이용할 경우**
  6 | </br>
  7 | 
  8 | ```java
  9 | Nutritionfact cocaCola = new Nutritionfact(240, 8, 100, 0, 35);
 10 | ```
 11 | 이렇게 생성자를 만들 수 있지만 어떤 속성 값을 설정했는지 알기 힘듭니다. **매개변수의 수가 늘어날 수록 코드를 작성하거나 읽기 힘들어집니다.** 문제는 매개변수 타입이 같은 상황에서 실수로 순서를 바꿔 입력할 경우 컴파일 시점에서 알 수 없고 **런타임에 엉뚱하게 동작하게 됩니다.**
 12 | </br></br>
 13 | 
 14 | ### **두번째 대안: 자바빈**
 15 | 또 다른 대안으로는 매개변수가 없는 생성자를 만든 뒤 `setter`를 통해서 값을 설정한는 방법입니다.
 16 | </br>
 17 | ```java
 18 | Nutritionfact cocaCola = new Nutritionfact();
 19 | cocaCola.setServingSize(240);
 20 | cocaCola.setServings(8);
 21 | cocaCola.setCalories(100);
 22 | ..
 23 | 반복
 24 | ```
 25 | 생성자를 이용한 방식보다 가독성이 훨씬 올라갔습니다. 하지만 객체가 완전히 생성되기 전까지는 중간에 사용할 수도 있으므로 일관성을 유지할 수 없습니다. 또한 불변 클래스로 만들 수 없다는 단점도 있으며(쓰레드 세이프하지 않습니다) 이를 해결하려면 추가 작업을 해줘야 합니다.
 26 | </br></br>
 27 | ### **세번째 대안: 빌더**
 28 | 발더 패턴은 필요한 매개변수만 전달할 수 있고 자바빈즈 패턴의 가독성을 모두 겸비한 대안입니다.</br></br>
 29 | 필수 매개변수만으로 생성자(혹은 정적팩토리)를 호출해 빌더 객체를 얻습니다.그 후 빌더 객체가 제공하는 일종의 세터 메서드들로 원하는 선택 매개변수를 설정합니다.</br>
 30 | 마지막으로 매개변수가 없는`build`메서드를 호출하여 객체를 생성합니다.
 31 | </br>
 32 | ``` java
 33 | // 예제에서 사용한 Builder패턴
 34 | 
 35 | public class NutritionFacts {
 36 | 
 37 |   private final int servingSize;
 38 |   private final int servings;
 39 |   private final int calories;
 40 |   private final int fat;
 41 |   private final int sodium;
 42 | 
 43 |   public static class Builder {
 44 | 
 45 |     // 필수 매개변수
 46 |     private final int servingSize;
 47 |     private final int servings;
 48 | 
 49 |     // 선택 매개변수 - 기본값으로 초기화 한다.
 50 |     private int calories = 0;
 51 |     private int fat = 0;
 52 |     private int sodium = 0;
 53 | 
 54 |     public Builder(int servingSize, int servings) {
 55 |       this.servingSize = servingSize;
 56 |       this.servings = servings;
 57 |     }
 58 | 
 59 |     public Builder calories(int val) {
 60 |       calories = val;
 61 |       return this;
 62 |     }
 63 | 
 64 |     public Builder fat(int val) {
 65 |       fat = val;
 66 |       return this;
 67 |     }
 68 | 
 69 |     public Builder carbohydrate(int val) {
 70 |       sodium = val;
 71 |       return this;
 72 |     }
 73 | 
 74 |     public NutritionFacts build() {
 75 |       return new NutritionFacts(this);
 76 |     }
 77 |   }
 78 | 
 79 |     private NutritionFacts(Builder builder) {
 80 |       this.servingSize = builder.servingSize;
 81 |       this.servings = builder.servings;
 82 |       this.calories = builder.calories;
 83 |       this.fat = builder.fat;
 84 |       this.sodium = builder.sodium;
 85 |   }
 86 | 
 87 | }
 88 | ```
 89 | ``` java
 90 | NutritionFacts cocaCola = new NutritionFacts.Builder(240, 8)
 91 | .calories(100)
 92 | .sodium(35)
 93 | .carbohydrate(27)
 94 | .build();
 95 | ```
 96 | </br>
 97 | 아까보다 가독성도 좋아지고 NutritionFacts 클래스는 불변이 되었습니다. 추상 클래스는 추상 빌더를 갖게하고 구체 클래스는 구체 빌더를 갖게 합니다.
 98 | 
 99 | ``` java
100 | public abstract class Pizza {
101 | 
102 |   public enum Topping { HAM, MUSHROOM, ONION, PEPPER, SAUSAGE }
103 |   final Set<Topping> toppings;
104 | 
105 |   abstract static class Builder<T extends Builder<T>> {
106 |     EnumSet<Topping> toppings = EnumSet.noneOf(Topping.class);
107 |     public T addTopping(Topping topping) {
108 |       toppings.add(Objects.requireNonNull(topping));
109 |       return self();
110 |     }
111 | 
112 |     abstract Pizza build(); // Pizza를 상속한 인스턴스를 반환하기만 하면 된다.
113 | 
114 |     // 하위 클래스는 이 메서드를 재정의 하여 "this"를 반환하도록 해야 한다.
115 |     protected abstract T self();
116 |   }
117 | 
118 |   Pizza(Builder<?> builder) {
119 |     toppings = builder.toppings.clone(); 
120 |   }
121 | 
122 | }
123 | ```
124 | </br>
125 | 
126 | ``` java
127 | public class NyPizza extends Pizza {
128 | 
129 |   public enum Size { SMALL, MEDIUM, LARGE }
130 |   private final Size size;
131 | 
132 |   public static class Builder extends Pizza.Builder<Builder> {
133 |     private final Size size;
134 | 
135 |     public Builder(Size size) {
136 |       this.size = Objects.requireNonNull(size);
137 |     }
138 | 
139 |     @Override
140 |     Pizza build() {
141 |       return new NyPizza(this);
142 |     }
143 | 
144 |     @Override
145 |     protected Builder self() {
146 |       return this;
147 |     }
148 | 
149 |   }
150 | 
151 |   private NyPizza(Builder builder) {
152 |     super(builder);
153 |     size = builder.size;
154 |   }
155 | 
156 | ```
157 | </br>
158 | 
159 | ``` java
160 | public class Calzone extends Pizza {
161 | 
162 |   private final boolean sauceInside;
163 | 
164 |   public static class Builder extends Pizza.Builder<Builder> {
165 |     private boolean sauceInside = false;
166 | 
167 |     public Builder sauceInde() {
168 |       sauceInside = true;
169 |       return this;
170 |     }
171 | 
172 |     @Override
173 |     public Calzone build() {
174 |       return new Calzone(this);
175 |     }
176 | 
177 |     @Override
178 |     protected Builder self() {
179 |       return this;
180 |     }
181 |   }
182 | 
183 |   private Calzone(Builder builder) {
184 |     super(builder);
185 |     sauceInside = builder.sauceInside;
186 |   }
187 | 
188 | }
189 | ````
190 | build 메서드는 하위 클래스 어떤 걸 반환해도 상관 없습니다. 하위 메서드가 상위 클래스의 메서드 정의한 반환 타입이 아닌, 그 하위 타입을 반환하는 기능을 공반환 타이핑이라 합니다.</br>
191 | ``` java
192 |     Pizza pizza = new Builder(SMALL)
193 |         .addTopping(SAUSAGE).addTopping(ONION).build();
194 | 
195 |     Calzone calzone = new Calzone.Builder()
196 |         .addTopping(HAM).sauceInde().build();
197 | ```
198 | 
199 | 빌더는 다양한 방식으로 객체를 생생할 수 있으므로 생성자와 정적 팩토리 메서드 방식보다 상당히 유연합니다.</br>
200 | 
201 | 단점으로는 객체를 생성하려면 Builder()를 생성해야하는데 성능에 민감한 상황에서는 이 점이 문제가 될 수 있습니다.그리고 생성자에 비해서 코드가 장황에 질 수 있으므로 현재 필요한 매개변수와 확장성을 고려해서 잘 판단하면 될 거 같습니다.
202 | 
203 | 


--------------------------------------------------------------------------------
/chap02/Item3.md:
--------------------------------------------------------------------------------
 1 | # [Item 3] private 생성자나 열거 타입으로  싱글턴임을 보증하라
 2 | 
 3 | 싱글턴(singletone)이란 인스턴스를 오직 하나만 생성할 수 있는 클래스를 말합니다. 즉 객체를 호출할 때마다 new해서 새로 생성하지 않고 하나의 인스턴스를 계속 사용하는 것입니다.</br>
 4 | 싱글턴을 만드는 방식은 보통 둘 중 하나입니다. 
 5 | 
 6 | ### **public static 멤버가 final인 방식**
 7 | ``` java
 8 | public class Elvis {
 9 | 
10 |   public static final Elvis INSTANCE = new Elvis();
11 | 
12 |   private void Elvis() { ... }
13 | 
14 |   private void leaveTheBuilding() { ... }
15 | 
16 | }
17 | ```
18 | public이나 protected 생성자가 없으므로 Elvis 클래스가 초기화 될 때 만들어진 인스턴스는 하나 뿐입니다. 단 권한이 있는 클라이언트는 리플렉션 API인 AccessibleObject.setAccessible을 사용해 private 생성자를 호출할 수 있습니다.</br>public 필드 방식의 첫번째 장점은 해당 클래스가 싱글턴임이 API에 명백히 드러나는 것입니다.</br>
19 | 두 번째 장점은 간결하다는 것입니다.
20 | 이 점은 생성자를 수정하여 두 번째 객체가 생성되려고 하면 예외를 단지면 됩니다. 
21 | 
22 | </br>
23 | 싱글턴을 만드는 두 번째 방법에는 정적 팩토리 메서드를 public static 멤버로 제공합니다.
24 | 
25 | ### **정적 팩토리 방식의 싱글톤**
26 | ``` java
27 | public class Elvis {
28 | 
29 |   private static final Elvis INSTANCE = new Elvis();
30 | 
31 |   private void Elvis() { ... }
32 |   public static Elvis getInstance() { return INSTANCE; }
33 | 
34 | 
35 |   private void leaveTheBuilding() { ... }
36 | 
37 | }
38 | ```
39 | 
40 | 이 역시 리플렉션을 통한 예외는 똑같이 적용됩니다.</br>
41 | 장점
42 | - API를 바꾸지 않고 싱글턴이 아니게 변경할 수 있습니다.
43 | - 유일한 인스턴스를 반환하던 팩터리 메서드가 호출하는 스레드별로 다른 인스턴스를 넘겨주게 할 수 있습니다.
44 | - 정적 팩토리 메서드 참조를 공급자(supplier)로 사용할 수 있습니다.
45 | </br>
46 | 
47 | 위에서 살펴본 두 방법 모두 직렬화하려면 모든 인스턴스 필드를 일시적(transient)이라고 선언하고 `readResolve` 메서드를 다음과 같이 제공해야 합니다. 
48 | ``` java
49 | private Object readResolve() {
50 |     returm INSTANCE;
51 | }
52 | ```
53 | 이렇게 하지 않으면 역직렬화 할때마다 새로운 인스턴스가 생성됩니다.</br></br>
54 | 
55 | ### **열거 타입의 방식의 싱글턴**
56 | ``` java
57 | public enum Elvis {
58 |     INSTANCEl
59 | 
60 |     public void leaveTheBuilding() { ... }
61 | }
62 | ```
63 | 직렬화 상황 그리고 리플렉션 공격에서도 싱글턴임을 보장할 수 있습니다. **대부분 상황에서는 원소가 하나뿐인 열거 타입이 싱글턴을 만드는 가장 좋은 방법입니다.**</br>
64 | 하지만 이 방법은 Enum 외의 클래스를 상속해야한다면 사용할 수 없습니다.(인터페이스를 구현할 수는 있습니다)
65 | 


--------------------------------------------------------------------------------
/chap02/Item4.md:
--------------------------------------------------------------------------------
 1 | # [Item 4] 인스턴스를 막으려거든 private 생성자를 사용하라
 2 | 
 3 | java.lang.Math와 java.util.Arrays와 같이 static 메서드와 static 필드만을 담을 클래스는 인스턴스화를 하는 건 낭비가 됩니다.
 4 | </br>
 5 | 매개변수 없는 생성자를 만들지 않으면 기본생성자가 생성이 되는데 이것을 방치하면 클라이언트 입장에서는 정적 멤버만 담은 유틸리티 클래스인지 알 수 없으므로 인스턴스화를 시킬 가능성이 있습니다. 이를 방지하기 위해 private 생성자를 만들어서 인스턴스화를 막을 수 있습니다.
 6 | </br>
 7 | ``` java
 8 | public class UtilityClass {
 9 | 
10 |   private UtilityClass() { }
11 |   
12 | }
13 | ```
14 | private 생성자이므로 상속을 시도하려는 클래스에서는 생성자를 호출할 수 없기 때문에 상속도 불가능 합니다.


--------------------------------------------------------------------------------
/chap02/Item5.md:
--------------------------------------------------------------------------------
 1 | # [Item 5] 자원을 직접 명시하지 말고 의존객체를 주입을 사용하여라.
 2 | 
 3 | 대부분의 클래스는 하나 이상의 리소스에 의존합니다. 이번 예제에서는 `SpellChecker`가 `Lexicon`를 의존하고 있는 모습입니다.
 4 | </br>
 5 | ## 부적절한 구현
 6 | ### **정적 유틸리티를 잘못 사용한 예 - 유연하지 않고 테스트 할 수 없다**
 7 | 
 8 | ``` java
 9 | public class SpellChecker {
10 | 
11 |   private static final Lexicon dictionary = ...;
12 | 
13 |   private SpellChecker() { } 
14 |   
15 |   public static boolean isValid(String word) { ... }
16 |   public static List<String> suggestions(String typo) { }  
17 | }
18 | ```
19 | ### **싱글턴을 잘못 사용한 예 - 유연하지 않고 테스트하기 어렵다**
20 | ``` java
21 | public class SpellChecker {
22 | 
23 |   private final Lexicon dictionary = ...;
24 | 
25 |   private SpellChecker() { }
26 |   public static SpellChecker INSTANCE = new SpellChecker();
27 | 
28 |   public static boolean isValid(String word) { ... }
29 |   public static List<String> suggestions(String typo) { ... }
30 | }
31 | ```
32 | 여기서 말하는 유연함이란 구현체를 변경하는 용이성을 말합니다.
33 | </br>
34 | 사용하는 리소스에 따라 행동을 다르게 해야하는 클래스는 위에 말한 두 방식을 사용하는 것은 부적절합니다. 이러한 불편 사항들을 해결하기 위해서는 인스턴스를 생성할 때 생성자에 자원을 넘겨주는 방식이 있습니다.
35 | ## 적절한 구현
36 | ### **의존 객체 주입은 유연성과 테스트 용이성을 높입니다.**
37 | </br>
38 | 
39 | ``` java
40 | public class SpellChecker {
41 | 
42 |   private final Lexicon dictionary;
43 | 
44 |   public SpellChecker(Lexicon dictionary) {
45 |     this.dictionary = dictionary;
46 |   }
47 | 
48 |   public static boolean isValid(String word) { ... }
49 |   public static List<String> suggestions(String typo) { }
50 | 
51 | }
52 | ```
53 | 흔히 생성자 주입 방식이라고 부르고 이러한 방식은 불변을 보장하며 원하면 하위 타입 인스턴스의 다양한 구현체를 주입할 수 있습니다.</br>
54 | 위와 같이 의존성을 주입하는 방식은 유연함과 테스트 용이함을 크게 향상시켜 주지만, 의존성이 많아질 경우 코드가 장황해질 수 있습니다.</br>
55 | 하지만 이 점은 스프링 같은 프레임워크로 해결할 수 있습니다. </br>
56 | 요약하자면 의존하는 리소스에 따라 행동을 달리하는 클레스를 사용할 때는 싱글턴이나 스태틱 유틸클래스를 사용하지말고
57 | 리소스를 생성자를 통해 의존성을 주입받는 걸 추천합니다.
58 | 


--------------------------------------------------------------------------------
/chap02/Item6.md:
--------------------------------------------------------------------------------
 1 | # [Item 6] 불피요한 객체를 생성을 피하라
 2 | 기능이 똑같은 객체를 매번 생성하기 보다는 객체를 재사용하는 것이 적절합니다. 특히 **불변 객체는 항상 재사용할 수 있습니다.**
 3 | 
 4 | ## **문자열 생성 방법**
 5 | ### **객체 생성 방식 - 피해야되는 예시**
 6 | ``` java
 7 | String str = new String("hello");
 8 | ```
 9 | 이 방식을 이용하면 똑같은 문자열을 생성하더라도 항상 새로운 객체를 생성하므로 낭비가 됩니다.
10 | ### **리터럴 방식**
11 | ``` java
12 | String str = "hello";
13 | ```
14 | `리터럴` 방식을 사용하면 JVM에서 동일한 문자열이 존재한다면 그 리터럴을 재사용합니다. 
15 | </br></br>
16 | 
17 | ## 생성 비용이 비싼 객체
18 | 생성 비용이 비싼 객체들 같은 경우 캐싱해서 재사용할 수 있는 방법을 고려해보는 게 좋습니다.
19 | 
20 | ### **불필요한 객체 생성 1**
21 | ``` java
22 | static boolean isRomanNumeral(String s) {
23 |     return s.matches("^(?=.)M*(C[MD]|D?C{0,3})"
24 |             + "(X[CL]|L?X{0,3})(I[XV]|V?I{0,3})$");
25 | }
26 | ```
27 | 정규표현식의 예제로 문자열이 로마 숫자인지 확인하는 코드입니다.</br>
28 | `String.matches`는 내부에서 만드는 `Pattern`객체를 만들어서 사용하는데, 이 메서드에서는 한 번 쓰고 버려져서 곧바로 가비지 컬렉션 대상이 됩니다. 입력받은 정규표현식에 해당하는 `유한 상태 머신`을 만들기 때문에 생성 비용이 비쌉니다.
29 | ### **해결책**
30 | ``` java
31 | public class RomanNumber {
32 | 
33 |     private static final Pattern ROMAN = Pattern.compile("^(?=.)M*(C[MD]|D?C{0,3})(X[CL]|L?X{0,3})(I[XV]|V?I{0,3})$");
34 | 
35 |     static boolean isRomanNumeral(String s) {
36 |         return ROMAN.matcher(s).matches();
37 |     }
38 | 
39 | }
40 | ```
41 | 성능을 개선한 코드 수정입니다.`Pattern`인스턴스 클래스 초기화 과정에서 직접 생성하고 캐싱해두었다가 해당 isRomanNumeral가 호출될 때마다 인스턴스를 재사용합니다. isRomanNumeral가 여러변 호출되는 상황에서 성능을 상당히 끌어올릴 수 있습니다.
42 | 
43 | ### **어댑터**
44 | 어댑터는 인터페이스를 통해서 다른 객체의 연결해주는 객체라 여러개 만들 필요가 없습니다.</br>
45 | 대표적으로 `Map` 인터페이스에 있는 `keySet` 메서드는 호출 될 때마다 새로운 객체가 나오는 게 아니라 같은 객체를 반환하기 때문에 리턴받은 `Set` 타입의 객체를 변경하면, 결국 그 뒤에 있는 `Map` 인터페이스도 변경되는 것입니다.
46 | 


--------------------------------------------------------------------------------
/chap02/Item7.md:
--------------------------------------------------------------------------------
 1 | # [Item 7] 다 쓴 객체 참조를 해제하라
 2 | **메모리 누수가 일어나는 예제 코드**
 3 | ``` java
 4 | public class Stack {
 5 |     private Object[] elements;
 6 |     private int size = 0;
 7 |     private static final int DEFAULT_INITIAL_CAPACITY = 16;
 8 | 
 9 |     public Stack() {
10 |         elements = new Object[DEFAULT_INITIAL_CAPACITY];
11 |     }
12 | 
13 |     public void push(Object e) {
14 |         ensureCapacity();
15 |         elements[size++] = e; 
16 |     }
17 | 
18 |     public Object pop() {
19 |         if (size == 0)
20 |             throw new EmptyStackException();
21 |         return elements[--size]; // 주의
22 |     }
23 | 
24 |     private void ensureCapacity() {
25 |         if (elements.length == size)
26 |             elements = Arrays.copyOf(elements, 2 * size);
27 |     }
28 | }
29 | ```
30 | 스택에서 데이터를 `pop`을 실행해도 메모리는 줄어들지 않습니다. 왜냐면 `size`를 감소 시키지만 배열에서 여전히 레퍼런스는 그대로 갖고있기 때문입니다.
31 | </br>
32 | 다음과 같이 코드를 수정할 수 있습니다.
33 | ``` java
34 |     public Object pop() {
35 |         if (size == 0) {
36 |             throw new EmptyStackException();
37 |         }
38 | 
39 |         Object value = this.elements[--size];
40 |         this.elements[size] = null;
41 |         return value;
42 |     }
43 | ```
44 | 
45 | size를 감소시킬 뿐만 아니라 실제로 해당 참조를 `null`로 처리한 방법입니다.
46 | </br>
47 | 하지만 객체 처리를 null로 처리하는 건 예외적인 경우여야 합니다. 다 쓴 참조를 해제하는 가장 좋은 방법은 다 쓴 참조를 담은 변수를 특정한 스코프 안에서만 사용하는 것입니다.
48 | </br></br>
49 | 캐시를 사용할 때도 메모리 누수에 유의해야 합니다. 
50 | - 외부에서 키를 참조하는 동안만 엔트리가 살아있는 캐시가 필요하다면 `WeakHashMap`을 사용합니다.
51 | - 시간이 지날 수록 엔티리의 가치를 떨어뜨리는 방식.
52 | 
53 | 
54 | 


--------------------------------------------------------------------------------
/chap02/Item8.md:
--------------------------------------------------------------------------------
 1 | # [Item 8] finalizer와 cleaner 사용을 피하라
 2 | 
 3 | 자바에서는 두 가지 객체 소멸자를 제공합니다. 바로 `finalizer`와 `cleaner`입니다. `finalizer`는 예측 불가능하며 일반적으로 불필요하며 오작동 낮은 성능과 같은 문제점들이 있습니다. 자바 9부터는 사용 자제(**deprecated**) API로 지정했습니다.
 4 | </br>
 5 | cleaner는 finalizer보다 덜 위험하지만 이 역시 예측 불가능하고, 느리고 일반적으로 불필요합니다.
 6 | ## 단점
 7 | ### **언제 실행되는지 알 수가 없다**
 8 | finalizer와 cleaner는 즉시 실행된다는 보장이 없습니다. 즉 제때 실행되어야 하는 작업을 절대 할 수 없다는 뜻입니다.
 9 | ### **finalizer는 굉장히 lazy 합니다**
10 | 여기서 lazy하다는 뜻은 인스턴스의 자원 회수가 멋대로 지연될 수 있다는 뜻입니다. 
11 | finalizer 쓰레드는 우선 순위가 낮아서 실행될 기회를 제대로 얻지 못하는 경우들도 생깁니다.
12 | ### **수행 여부가 보장되지 않습니다**
13 | 자바 언어 명세는 finalizer와 cleaner의 수행 시점과 수행 여부조차 보장하지 않습니다.
14 | 따라서 **상태를 수정하는 작업에는 절대 finalizer나 cleaner에 의존해서는 안 됩니다.**
15 | ### **예외가 무시됩니다.**
16 | finalizer가 동작하면서 발생한 예외는 무시되며 처리할 작업이 남아있더라도 그 순간 종료됩니다. finalzer같은 경우 예외가 발생해도 추적을 할 수 없으며 이는 디버깅하는데 큰 문제가 됩니다.
17 | ### **성능상 이슈**
18 | `Autocloseable` 객체를 만들고 가비지 컬렉터가 수거하기 전까지 12ns가 걸린 반면, finalizerf를 사용하면 550ns가 소요 됐습니다. finalizer가 가비지 컬렉터의 효율을 떨어뜨리기 때문입니다.</br>
19 | </br>뿐만 아니라 다양한 이슈들로 인해 `finalizer`와 `cleaner`의 사용을 추천하고 있지 않습니다.


--------------------------------------------------------------------------------
/chap02/Item9.md:
--------------------------------------------------------------------------------
 1 | # [Item 9] try-finally보다는 try-with-resources를 사용하라
 2 | 자바 라이브러리에는 `InputStream`, `OutputStream`, `java.sql.Connection`과 같이 직접 닫아(close)해줘야 하는 자원들 있습니다. 클라이언트는 실수로 자원을 닫아주지 않는 경우 예상치 못한 성능 문제로 이어질 수 있습니다.
 3 | ``` java
 4 |   static String firstLineOfFile(String path) throws IOException {
 5 | 
 6 |     BufferedReader br = new BufferedReader(new FileReader(path));
 7 |     try {
 8 |       return br.readLine();
 9 |     } finally {
10 |       br.close();
11 |     }
12 |   }
13 | ```
14 | 나쁘진 않지만 자원을 더 사용하게 되면 살수가 나올 가능성이 큽니다.
15 | 위 예제 같은 경우 try 블록과 finally 블록 모두에서 발생할 수 있는데, 예컨데 기기에 물리적 문제가 생긴다면 firstLineOfFile 메서드 안의 readLine 메서드가 예외를 던지고, 같은 이유로 close 메서드도 실패합니다. 이런 상황이라면 두 번째 예외가 첫 번째 예외를 완전히 집어삼키게 됩니다.(첫 번째 예외는 정보가 남지 않게 됩니다)
16 | </br></br>
17 | 이러한 문제점들을 고안해서 자바 7부터는 `try-with-resources`으로 해결할 수 있습니다. 이 구조를 사용하려면 해당 자원이 AutoCloseable 인터페이스를 구현해야 합니다.</br>자바 라이브러리와 서드파티 라이브러리들의 수많은 클래스와 인터페이스가 이미 Autocloseable을 구현하거나 확정했습니다.</br>
18 | try-with-resources를 사용한 코드
19 | ``` java
20 |   static String firstLineOfFile(String path) throws IOException {
21 |     try (BufferedReader br = new BufferedReader(new FileReader(path))) {
22 |       return br.readLine();
23 |     }
24 | ```
25 | try-with-resources에서도 catch 절을 사용할 수 있습니다.
26 | ``` java
27 |   static String firstLineOfFile(String path) {
28 |     try (BufferedReader br = new BufferedReader(new FileReader(path))) {
29 |       return br.readLine();
30 |     } catch (IOException e) {
31 |       return defaultVal;
32 |     }
33 |   }
34 | ```
35 | 
36 | 


--------------------------------------------------------------------------------
/chap03/Item10.md:
--------------------------------------------------------------------------------
 1 | # [Item 10] equals는 일반 규약을 지켜 재정의하라.
 2 | equals 메서드를 오버라이딩 하는 경우는 논리적인 동치성을 확인하기 위해서입니다.여기서 말하는 논리적 동치성은 쉽게 말하자면 참조값을 비교하는 게 아닌 객체의 값이 같은지 비교하기 위함이라고 할 수 있습니다.</br></br>
 3 | equals메서드를 오버라아딩 할 때는 다음의 규약을 따라야 합니다.
 4 | </br>
 5 | ### **반사성(reflexivity)**
 6 | - null이 아닌 모든 참조 값 x에 대해, x.equals(x)는 true입니다.
 7 | ### **대칭성(symmetry)**
 8 | - null이 아닌 모든 참조 값 x, y에 대해 x.equals(y)는 y.equals(x)입니다.
 9 |  
10 | **잘못된 코드 - 대칭성 위반**
11 | ``` java
12 | public class CaseInsensitiveString {
13 | 
14 |   private String str;
15 |   
16 |   ... 생략
17 | 
18 |   @Override
19 |   public boolean equals(Object o) {
20 |     if (o instanceof CaseInsensitiveString) {
21 |       return str.equalsIgnoreCase(((CaseInsensitiveString) o).str);
22 |     }
23 |     if (o instanceof String) {
24 |       return str.equalsIgnoreCase((String) o);
25 |     }
26 |     return false;
27 |   }
28 | }
29 | ```
30 | ``` java
31 | CaseInsensitiveString cis = new CaseInsensitiveString("String");
32 | String str = "string";
33 | ```
34 | cis.equals(str)는 true를 반환하고 str.equals(cis)는 false를 반환하게 되므로 대칭성에 위반됩니다.
35 | 
36 | ### **추이성(transitivity)**
37 | - null이 아닌 모든 참조 값 x, y, z에 대해 x.equals(y)가 true고 y.equals(z)도 true입니다.
38 | ### **일관성(consistency)**
39 | - null이 아닌 모든 참조 값 x, y에 대해 x.equals(y)를 반복해서 호출하면 항상 true를 반환하거나 항상 false를 반환해야 합니다.
40 | ### **null-아님**
41 | - null이 아닌 모든 참조 값 x에 대해 x.equals(null)은 false다
42 | 
43 | 이제 상위 클래스에 없는 필드를 하위 클래스에 추가하는 상황을 생각해봅시다. 여기서부터 신경써야 할 부분들이 많아집니다.
44 | ``` java
45 | public class Point {
46 | 
47 |   private int x;
48 |   private int y;
49 | 
50 |   ... 생략
51 | 
52 |   @Override
53 |   public boolean equals(Object o) {
54 |     if (!(o instanceof Point)) {
55 |       return false;
56 |     }
57 |     Point p = (Point) o;
58 |     return this.x == p.x && this.y == p.y;
59 |   }
60 | }
61 | ```
62 | Point클래스를 확장해봅시다.
63 | ``` java
64 | public class CirclePoint extends Point{
65 | 
66 |   private int x;
67 |   private int y;
68 |   private int z;
69 | 
70 |   public CirclePoint(int x, int y, int z) {
71 |     super(x, y);
72 |     this.z = z;
73 |   }
74 | 
75 |   ... 생략
76 | }
77 | ```
78 | 이대로 사용하면 Point의 구현이 상속되어 x, y만 비교하게 되므로 생각했던 결과랑 실제 결과값이 다르게 나오는 상황이 발생합니다.</br>
79 | 객체 지향의 추상화의 이점을 포기하지 않는 이상 아쉽게도 이러한 문제점들을 모두 완전하게 해결할 수 있는 방법은 없습니다.
80 | </br>
81 | ### **양질의 equals메서드 구현 단계**
82 | 1.  == 연산자를 사용해 입력이 자기 자신의 참조인지 확인합니다.
83 | 2.  **insetanceof** 연산자로 입력이 올바른 타입인지 확인합니다.
84 | 3.  입력을 올바른 타입으로 형변환 합니다.
85 | 4.  입력받은 객체와 자기 자신의 대응되는 필드들이 모두 일치하는지 검사합니다.
86 | 
87 | 어떤 필드를 먼저 비교하느냐에 따라 성능의 차이도 생깁니다. 값이 다를 가능성이 크거나 비교하는 비용이 싼 필드를 먼저 비교하면 성능상 이점을 얻을 수 있습니다.(틀리면 다음 로직을 실행하지 않기에)
88 | 
89 | 


--------------------------------------------------------------------------------
/chap03/Item11.md:
--------------------------------------------------------------------------------
 1 | # [Item 11] equals를 재정의하려거든 hashCode도 재정의하라.
 2 | 
 3 | equals와 hasoCode를 재정의 하지 않으면 `HashMap`이나 `HashSet`에서 같은 원소를 사용할 때 문제가 발생합니다.
 4 | </br>
 5 |   1. equals 비교에 사용되는 정보가 변경되지 않는다면, 애플리케이션이 실행되는 동안 객체의 hashCode메서드는 여러번 호출해도 일관된 값을 반환해야 합니다.
 6 |   2. equals가 두 객체를 같다고 판단하면 hashCode 또한 같은 값을 반환해야 합니다.
 7 |   3. equals가 두 객체를 다르다고 판단해도, 두 객체의 hashCode가 서로 다른 값을 반환할 필요는 없습니다. 단, 다른 객체에 대해서는 다른 값을 반환해야 해쉬테이블의 성능이 좋아집니다.
 8 | 
 9 | 서로 다른 인스턴스에 대해서 모두 다른 해시코드를 반환하면 좋겠지만 hashCode는 int형이므로 2^32만큼의 경우의 수로 제한되어 있기 때문에 비둘기 집의 원리로 예외가 생길 수 있습니다.</br>
10 | 다음은 hashCode를 작성하는 요령입니다.
11 | 
12 | 1. int 변수 result를 선언한 후 값 c로 초기화 합니다. 이때 c는 해당 객체의 첫번째 핵시 필드를 2-a 방식으로 계산한 해시코드입니다.
13 | 2. 해당 개게의 나머지 필드 f 각각에 대해서 다음 작업을 수행합니다.</br>
14 |    a. 해당 필드의 해시코드를 c를 계산합니다.</br>
15 |    - 기본 타입 필드라면, Type.hashCode(f)를 수행합니다. 여기서 Type은 해당 기본 타입의 박싱 클래스입니다.
16 |    - 참조 타입 필드면서 이 클래스의 equals 메서드가 이 필드의 equals를 재귀적으로 호출해 비교한다면, 이 필드의 hashCode를 재귀적으로 호출합니다.
17 |    - 필드가 배열이라면, 원소 각각을 별도 필드처럼 다룹니다. 이상의 규칙을 재귀적으로 적용해 각 핵심 원소의 해시코드를 게산한 다음, 2.b방식으로 갱신합니다. 배열에 핵심 원소가 하나도 없다면 단순 상수를 사용하고 모든 원소가 핵심 원소라면 Arrays.hashCode를 사용합니다.
18 |    - 
19 |    </br>
20 |      b. 단계 2.a에서 계산한 해시코드 c로 result를 갱신합니다.
21 |      result = 31 * result + c;
22 | </br>
23 | 3. result를 반환합니다.
24 | 
25 | </br>
26 | 
27 | `equals` 비교에서 사용되지 않는 필든 '반드시'제외해야 합니다. 그렇지 않으면 맨 처음에 언급했던 두 번째 규약을 어기게됩니다.</br>
28 | 숫자를 곱하는 이유는 만약 곱셉 없는 hahCode를 구현하게 되면 모든 아나그램의 해시코드가 같아집니다. 그리고 31을 선택한 이유는 홀수이면서 소수이기 때문입니다.</br>
29 | ``` java
30 | 전형적인 hashCode 메서드
31 | 
32 | @Override
33 | public int hashCode() {
34 |     int result = Short.hashCode(areaCode);
35 |     result = 31 * result + Short.hashCode(prefix);
36 |     result = 31 * result + Short.hashCode(lineNum);
37 |     return result;
38 | }
39 | ```
40 | ``` java
41 | 한 줄짜리 hasoCode 메서드 - 성능이 살짝 아쉽습니다.
42 | @Override 
43 | public int hashCode(){
44 |     return Objects.hash(lineNum, prefix, areaCode);
45 | }
46 | ```
47 | ### 정리
48 | `equals`를 재정의 할 때는 `hashCdoe`도 재정의해야 합니다. 그렇지 않으면 프로그래밍이 제대로 동작하지 않을 수 있습니다. 서로 다른 인스턴스라면 되도록 해시코드도 서로 다르게 구현해야 합니다.
49 | 


--------------------------------------------------------------------------------
/chap03/Item12.md:
--------------------------------------------------------------------------------
 1 | # [Item 12] toString을 항상 재정의하라.
 2 | toString을 오버라이딩 하지 않으면 기본적으로 **클래스_이름@16진수로_표현한_해시코드**를 반환합니다. </br>
 3 | 이렇게 되면 객체의 특성을 알아볼 수 있으므로 `toString`을 재정의 할 필요가 있습니다.
 4 | ``` java
 5 | Student student = new Student("kim", 16);
 6 | System.out.println(student);
 7 | ```
 8 | 위 코드를 실행하면 Student@abcd같은 형태로 콘솔에 출력되므로 객체의 특성을 파악하기가 힘듭니다.
 9 | 
10 | ### **toString 재정의하는 좋은 방법.**
11 | - 객체가 가진 가진 **주요 정보를 모두 반환**하는 게 좋습니다.
12 | - toString을 구현하면 반환값의 포맷을 문서화할지 정해야 합니다.
13 |   - 규칙이 명확해지는 장점이 있지만, 한번 명시하면 그 포맷에 얽매이게 됩니다.
14 |   - 이러한 문제는 롬복으로 해결할 수 있습니다.
15 | - 포맷을 명시하든 아니든 여러분의 **의도**는 명확하게 밝혀져야합니다.
16 | - toString이 반환한 값에 포함된 정보를 얻어올 수 있는 API를 제공합시다.
17 | 
18 | ### **정리**
19 | 객체의 정보를 출력할 일이 있으면 toString을 재정의 합시다. toString을 재정의하면 사용자가 보기 편하고 디버깅을 쉽게 해줍니다. toString은 객체에 관해 명확하고 정보를 읽기 좋은 형태로 반환해야합니다.


--------------------------------------------------------------------------------
/chap03/Item13.md:
--------------------------------------------------------------------------------
 1 | # [Item 13] clone 재정의는 주의해서 진행하라.
 2 | 
 3 | 실무에서 `Cloneable`을 구현한 클래스는 clone 메서드를 public으로 제공하며, 사용자는 당연히 복제가 제대로 이뤄지리라 기대합니다.
 4 | 하지만 clone 메서드의 일반 규약은 허술한 부분이 있습니다. 다음은 Object 명세에서 가져온 설명입니다.
 5 | </br></br>
 6 | 이 객체의 복사본을 생성해 반환합니다. '복사'의 정확한 뜻은 그 객체를 구현한 클래스에 따라 다를 수 있지만 일반적은 의도는 다음과 같습니다. 어떤 객체 x에 대해 다음 식은 참입니다.
 7 | - x.clone() != x
 8 | - x.clone.getClass() = x.getClass()
 9 | - x.clone().equals(x)
10 | 
11 | clone을 사용하는 방법은 굉장히 쉽습니다. Cloneable인터페이스를 구현하고 super.clone을 호출하면 됩니다. 이렇게 얻은 객체는 원본의 모든 필드랑 똑같은 값을 가지게 됩니다.
12 | ``` java
13 | @Override
14 | public PhoneNumber clone() {
15 |     try{
16 |         return (PhoneNumber) super.class();
17 |     } catch (CloneNotSupportedException e) {
18 |         throw new AssertionsError();
19 |     }
20 | }
21 | ```
22 | Obejct의 clone은 Object를 반환하지만 공변 반환 타입을 이용해서 PhoneNumber로 반환했습니다. 이 방식으로 사용하는 클라이언트는 형변환을 따로 해줄 필요가 없습니다.
23 | </br>
24 | 간단했던 앞서의 구현이 클래스가 가변 객체를 참조하는 순간 문제점이 발생합니다.
25 | ``` java
26 | public class Stack {
27 |     private Object[] elements;
28 |     private int size = 0;
29 |     private static final int DEFAULT_INITIAL_CAPACITY = 16;
30 |     
31 |     public Stack() {
32 |         this.elements = new Object[DEFAULT_INITIAL_CAPACITY];
33 |     }
34 | 
35 |     ... 생략
36 | }
37 | ```
38 | clone 메서드가 단순히 super.clone의 결과를 그대로 반환하면 Stack인스턴스의 size 필드는 올바른 값을 갖겠지만, elements필드는 원본 Stack 인스턴스와 똑같은 배열을 참조하게 되는 상황이 발생합니다.</br>
39 | clone메서드는 사실상 생성자와 같은 효과를 냅니다. 즉 clone은 원본 객체에 아무런 변화가 없는 동시에 복제된 객체의 **불변식을** 보장해야 합니다.
40 | ``` java
41 | // 가변 상태를 참조하는 클래스용 clone 메서드
42 | @Override
43 | public PhoneNumber clone() {
44 |     try{
45 |         Stack result = (Stack) super.clone();
46 |         result.elements = elements.clone();
47 |         return result;
48 |     } catch (CloneNotSupportedException e) {
49 |         throw new AssertionsError();
50 |     }
51 | }
52 | ```
53 | 
54 | 
55 | 


--------------------------------------------------------------------------------
/chap03/Item14.md:
--------------------------------------------------------------------------------
 1 | # [Item 14] Comparable를 구현할지 고려하라
 2 | 자바에서는 `Comparable`과 `Comparator`이라는 정렬 인터페이스를 제공합니다. Comparable은 기본 정렬기준을 구현하는 데 사용하고, Comparator은 기본 정렬기준 외에 다른 기준으로 정렬하고자 할 때 사용합니다. 여기서는 Comparable의 하나 밖에 없는 `compareTo`메서드에 대해서 알아봅시다.
 3 | </br>
 4 | Comparable을 구현했다는 것은 그 클래스의 인스턴스들에는 `natural order`가 있음을 의미합니다.</br>
 5 | 그래서 Comparable을 구현한 객체들의 배열은 다음과 같이 정렬할 수 있습니다.
 6 | ``` java
 7 | Arrays.sort(a);
 8 | ```
 9 | 
10 | ### **compareTo 메서드의 규약**
11 | 이 객체가 주어진 객체(매개변수로 받는)보다 작으면 음의 정수를, 같으면 0을, 크면 양의 정수를 반환합니다. 이 객체와 비교할 수 없는 타입이면 ClassCastException을 던집니다.</br>
12 | 다음 설명에서는 sgn(표현식) 표기는 수학에서 말하는 부호 함수를 뜻하며, 표현식의 값이 음수, 0, 양수일 때 -1, 0, 1을 반환하도록 정의했습니다. 
13 | - Comparable을 구현한 클래스는 모든 x, y에 대해 sgn(x.comparaTo(y)) == -sgn(y.comparaTo(x))여야 합니다.(따라서 x.compareTo(y))는 y.compareTo(x)가 예외를 던질 때에 한해 예외를 던져야 합니다.
14 | - Comparable을 구현한 클래스는 추이성을 보장해야 합니다. x.comparaTo(y) > 0 && y.comparaTo(z) > 0이면 x.compareTo(z) > 0입니다.
15 | - Comparable을 구현한 클래스는 모든 z에 대해 x.compareTo(y) == 0이면 sgn(x.compareTo(z)) == sgn(y.compareTo(z))입니다.
16 | - 이번 권고가 필수는 아니지만 꼭 지키는 게 좋습니다. (x.compareTo(y) == 0) == (x.equals(y))여야 합니다.
17 | 
18 | hashCode 규약을 지키지 못하면 해시를 사용하는 클래스에서 오작동이 날 수 있듯이 compareTo 규약을 지키지 못하면 TreeSet, TreeMap과 같이 비교를 활용하는 클래스에서 오작동이 날 수 있습니다.
19 | </br>
20 | Compareble 인터페이스은 타입 인수를 받는 제네릭 인터페이스므로 compareTo 메서드의 인수 타입은 컴파일타임에 정해집니다. 즉 매개변수 타입이 잘못 됐다면 컴파일 자체가 되지 않으므로 형변환 할 필요가 없다는 뜻입니다.</br>
21 | 객체 참조 필드를 비교하려면 compareTo 메서드를 재귀적으로 호출합니다. Compareble을 구현하지 않은 필드나 표준이 아닌 순서로 비교해야 한다면 `Comparator`를 사용하면 됩니다.
22 | </br></br>
23 | 클래스의 핵심 필드가 여러개라면 가장 핵심적인 필드부터 비교하는 것을 추천드립니다. 비교 결과가 0이 아니라면 순서는 거기서 셜정되기 떄문입니다.</br>
24 | **자바8에서 compareTo 메서드를 구현하기**
25 | ``` java
26 |     List<Student> students = Arrays.asList(
27 |         new Student(30,  "kim"),
28 |         new Student(50,  "jake"),
29 |         new Student(50,  "foo")
30 |     );
31 | 
32 |     students.sort(
33 |         Comparator.comparingInt(Student::getAge)
34 |             .thenComparing(Student::getName)
35 |     );
36 |     // 이뿐만 아니라 다양한 방식으로 정렬을 할 수 있습니다.
37 | ```
38 | 이런식으로 간결하게 코드를 짤 수 있습니다. 대신 약간의 성능 저하가 있습니다. 
39 | 
40 | 
41 | 
42 | 


--------------------------------------------------------------------------------
/chap04/Item15.md:
--------------------------------------------------------------------------------
 1 | # [Iteam 15] 클래스와 멤버의 접근 권한을 최소화하라.
 2 | 
 3 | 
 4 | 잘 설계된 컴포넌트와 그렇지 못한 컴포넌트의 가장 큰 차이는 클래스 내부 데이터와 내부 구현 정보를 외부 컴포넌트로부터 얼마나 잘 숨겼느냐입니다. 설계가 잘 된 컴포넌트는 모든 내부 구현을 숨겨, 구현과 API를 깔끔하게 **분리**합니다. 
 5 | 
 6 | ### **정보 은닉(캠슐화)의 장점**
 7 | - 시스템 개발 속도를 높입니다. (여러 컴포넌트를 병렬로 개발할 수 있기 때문에)
 8 | - 시스템 관리 비용을 낮춥니다. (각 컴포넌트를 더 빨리 파악하여 디버깅할 수 있고, 다른 컴포넌트로 교체하는 비용도 적기 때문에)
 9 | - 성능 최적화에 도움을 줍니다. (다른 컴포넌트에 영향을 주지 않고 특정 컴포넌트만 최적화 할 수 있어서)
10 | - 재사용성을 높입니다. (독자적으로 동작하는 컴포넌트는 다른 환경에서도 쓰일 수 있기 때문에)
11 | 
12 | 접근 제어자를 잘 활용하는 것이 정보 은닉의 핵심입니다.</br>
13 | 가본 원칙은 모든 클래스와 멤버의 접근성을 가능한 좁혀야 합니다. 즉 애플리케이션이 제대로 동작하는 한 항상 가장 낮은 접근 수준을 부여해야 합니다.</br></br>
14 | 톱레벨(가장 바깥) 클래스와 인터페이스에 부여할 수 있는 접근 제어자는 `public`과 `package-private`(default) 두 가지 입니다.
15 | </br>
16 | public으로 선언하면 공개 API가 되므로 패키지 외부에서 쓸 일이 없다면 package-private로 선언하는 걸 권장합니다.</br></br>
17 | 
18 | 한 클래스에서만 사용하는 package-private 톱레벨 클래스나 인터페이스는 이를 사용하는 클래스 안에 private static으로 중첩시켜봅시다. 이렇게 하면 바깥 클레스 하나에서만 접근할 수 있습니다.
19 | </br></br>
20 | 
21 | **멤버**(필드, 메섣, 중첩 클래스, 중첩 인터페이스)에 사용할 수 있는 **접근제한자**
22 | 
23 | - **private**: 멤버를 선언한 톱레벨 클래스에서만 접근 가능합니다.
24 | - **package-private**: 멤버가 소속된 패키지안에 모든 클래스에서 접근 가능합니다
25 | -  **protected**: package-private + 하위  클래스
26 | -  **public**: 모든 곳에서 접근할 수 있습니다.
27 | ### public 클래스의 인스턴스 필드는 가능한 public이 아니어야 합니다.
28 | 필드가 가변 객체를 참조하거나, final이 아닌 인스턴스필드를 public으로 선언하면 필드의 내용이 수정될 수 있으므로 불변을 보장할 수 없게 되므로 유의해야 합니다. 필드가 final이면서 불변 객체를 참조해도 문제는 있습니다. 내부 구현을 바꾸고 싶어도 public 필드를 없애는 방식으로는 리팩터링 할 수 없게 됩니다.</br>
29 | 정적 필드 같은 경우 추상 개념을 완성하는데 꼭 필요한 구성요소로써의 상수라면 public static final필드로 공개해도 좋으나 반드시 `primitive type`이나 `불변 객체`를 참조해야 합니다. 가변 객체를 참조한다면 참조는 변경하지 못하나 객체 값은 수정될 수 있으므로 주의해야 합니다.</br>
30 | 
31 | 
32 | > 정리 </br>
33 | > 프로그램의 접근 제어자는 가능한 **최소한**으로 합시다. 꼭 필요한 것만 public API를 설계하고 그 외에는 의도치 않게 API로 공개되는 일이 없도록 해야 합니다. public클래스는 public static final 필드 외에는 어떠한 public 메서드도 가져서는 안 됩니다. 또한 public static final 필드가 참조하는 객체가 불변인지 확인합시다.
34 | 


--------------------------------------------------------------------------------
/chap04/Item16.md:
--------------------------------------------------------------------------------
 1 | # [Item 16] public 클래스에서는 public 필드가 아닌 접근 메서드를 사용하라.
 2 | 
 3 | ``` java
 4 | // 부적적한 코드
 5 | public class Point {
 6 |   public int x; 
 7 |   public int y;
 8 | }
 9 | 
10 | ```
11 | 위 코드는 객체지향의 특징 중 하나인 캡슐화를 살리지 못했습니다.</br>
12 | 다음과 같이 추상화의 이점을 살려서 코드를 수정할 수 있습니다.
13 | ``` java
14 | public class Point {
15 |   public int x;
16 |   public int y;
17 | 
18 |   public Point(int x, int y) {
19 |     this.x = x;
20 |     this.y = y;
21 |   }
22 | 
23 |   public int getX() { return x; }
24 |   public int getY() { return y; }
25 | 
26 |   public void setX(int x) { this.x = x; }
27 |   public void setY(int y) { this.y = y; }
28 | }
29 | 
30 | ```
31 | 외부에서 접근할 수 있는 클래스라면 접근자를 제공함으로써 클래스 내부 표현 방식을 변경할 수 있는 유연성을 얻을 수 있습니다. </br>
32 | public 클래스의 불변이라면 직접 노출할 때의 단점이 줄어들지만 여전히 문제점은 있습니다. API를 변경하지 않고는 표현 방식을 바꿀 수 없고, 필드를 읽을 때 부수 작업을 수행할 수 없다는 단점이 있습니다. 하지만 불변식은 보장할 수 있습니다. 
33 | > 정리</br>
34 | > public 클래스의 가변 필드는 절대 노출해서는 안 됩니다. 불변 필드라면 위험은 덜 하지만 완전히 안심할 수는 없습니다. 하지만 package-private 클래스나 private 중첩 클래스에서는 필드를 노출하는 편이 나을 때도 있습니다.


--------------------------------------------------------------------------------
/chap04/Item17.md:
--------------------------------------------------------------------------------
 1 | # [Item 17] 변경 가능성을 최소화하라.
 2 | 
 3 | **불변** 클래스(Immutable Class)란 말 그대로 객체가 생성된 후에 더이상 값을 변경할 수 없는 것을 의미합니다. 자바에서는 대표적으로 `String`, `Integer`, `Float`,`Long` 등이 있습니다.</br>
 4 | **불변 클래스의 장점**
 5 | 
 6 | ### 클래스를 불변으로 만들기 위한 규칙
 7 | - 객체의 상태를 변경하는 메서드를 제공하지 않습니다.
 8 | - 클래스를 확장할 수 없도록 합니다.
 9 | - 모든 필드를 private final으로 선언합니다.
10 | - 생성자 관리를 잘할 것 (밑에서 설명)
11 | - 자신 외에는 내부에 가변 컴포넌트에 접근할 수 없도록 합니다.
12 | 
13 | ``` java
14 | public final class Calculator {
15 |   private final int x;
16 |   private final int y;
17 | 
18 |   public Calculator(int x, int y) {
19 |     this.x = x;
20 |     this.y = y;
21 |   }
22 | 
23 |   public Calculator plus(Calculator c) {
24 |     return new Calculator(x + c.x, y + c.y);
25 |   }
26 | 
27 |   public Calculator minus(Calculator c) {
28 |     return new Calculator(x - c.x, y - c.y);
29 |   }
30 | 
31 |   ... 생략
32 | }
33 | ```
34 | 여기서 주목할 점은 메서드들이 인스턴스 자신을 수정하지 않고 새로운 `Calculator` 인스턴스를 만들어 반화하는 것입니다. 
35 | ### 불변 객체의 장점
36 | - 불변 객체는 Thread-Safe 하므로 멀티 쓰레드 환경에서 안전하게 사용할 수 있습니다.
37 | - 불변 객체는 하나의 상태만을 갖고 있으므로 데이터를 신뢰할 수 있습니다.
38 | 
39 | 따라서 불변 클래스라면 한번 만든 인스턴스를 최대한 재활용 하길 추천합니다. 재활용 하기 가장 쉬운 방법은 자주 쓰이는 값들을 상수로 제공하는 것입니다.
40 | ``` java
41 | public static final Calculator ONE = new Calculator(1, 0);
42 | ...
43 | ```
44 | 이 방식을 더 살펴보면 불변 클래스는 자주 사용되는 인스턴스를 캐싱하여 같은 인스턴스를 중복 생성하지 않게 해주는 정적 팩터리를 제공할 수 있습니다. 대표적으로 박싱된 기본 타입 클래스가 있습니다.</br>
45 | 이런 정적 팩터리를 사용하면 여러 클라이언트가 인스턴스를 공유하여 메모리 사용량과 가비지 컬렉션 비용이 줄어듭니다. 하지만 붋변 객체에도 **단점**이 있습니다.**값이 다르면 반드시 독립된 객체로 만들어야** 합니다. (성능 이슈)
46 | ### 불변 클래스를 만드는 설계 방법
47 | 
48 | 클래스가 불변임을 보장하려면 자신을 상속하지 못하게 해야하는데 가장 쉬운 방법은 final으로 선언해주는 것입니다. 하지만 이것보다 더 유연한 방법이 있습니다. 모든 생성자를 private 혹은 package-private으로 만들고 public 정적 펙터리를 제공하는 방법입니다.
49 | ``` java
50 | public final class Calculator {
51 |   private final int x;
52 |   private final int y;
53 | 
54 |   private Calculator(int x, int y) {
55 |     this.x = x;
56 |     this.y = y;
57 |   }
58 | 
59 |   public static Calculator valueOf(int x, int y) {
60 |     return new Calculator(x, y);
61 |   }
62 |   ...
63 | 
64 | ```
65 | 정적 팩토리 방식으로 다수의 구현 클래스를 활용해 유연성을 제공하고, 객체 캐싱 기능을 추가해 성능을 끌어올리 수 있습니다.</br></br>
66 | ### `BigInteger`와 `BigDecimal`의 주의점</br>
67 | 두 클래스를 설계할 당시 불변 객체가 final이어야 한다는 인식이 없었습니다. 그래서 두 클래스의 메서드들은 모두 재정의할 수 있게 설계 되었고 하위 호환성이 발목을 잡아 지금까지도 이 문제를 고치지 못했습니다. 그러므로 신뢰할 수 없는 클라이언트로부터 `BigInteger`와 `BigDecimal`의 인스턴스를 인수로 받는다면 주의해야 합니다.
68 | ``` java
69 | public static BigInteger safeInstance(BingInteger val) {
70 |   return val.getClass() == BigInteger.class ?
71 |           val : new BigInteger(val.toByteArray());
72 | }
73 | ```
74 | </br>
75 |  정리
76 | -   **클래스는 꼭 필요한 경우가 아니면 불변이어야 합니다**. 
77 | -   불변 클래스의 장점들도 있지만 성능 문제도 함께 고려해야합니다
78 | -   불변으로 만들 수 없는 클래스라도 변경할 수 있는 부분은 최소한으로 줄입시다.
79 | -   다른 합당한 이유가 없다면 모두 private final이어야 합니다.
80 | -   생성자는 불변식 설정 초기화가 완벽히 끝난 상태의 객체를 생성해야 합니다.


--------------------------------------------------------------------------------
/chap04/Item18.md:
--------------------------------------------------------------------------------
 1 | # [Item 18] 상속보다는 컴포지션을 사용하라.
 2 | 우선 이번 아이템에서 다루는 상속은 클래스가 다른 클래스를 확장하는 것을 말합니다. </br>
 3 | 상속 같은 경우 상위 클래스가 구현 방식에 따라 하위 클래스 동작에 영향을 미칠 수 있습니다.
 4 | </br>
 5 | **예제를 위한 코드**
 6 | ``` java
 7 | public class CustomHashSet<E> extends HashSet<E> {
 8 |   private int addCount = 0;
 9 | 
10 |   public CustomHashSet() { }
11 | 
12 |   @Override
13 |   public boolean add(E e) {
14 |     addCount++;
15 |     System.out.println("hello");
16 |     return super.add(e);
17 |   }
18 | 
19 |   @Override
20 |   public boolean addAll(Collection<? extends E> c) {
21 |     addCount += c.size();
22 |     return super.addAll(c);
23 |   }
24 | 
25 |   public int getAddCount() {
26 |     return addCount;
27 |   }
28 | 
29 | }
30 | ```
31 | ```java
32 |     CustomHashSet<String> set = new CustomHashSet<>();
33 |     set.addAll(Arrays.asList("가","나","다"));
34 |     System.out.println(set.getAddCount());
35 |   }
36 | ```
37 | 원소를 3개 삽입했지만 addCount출력하면 결과값은 `6`이 나옵니다.
38 | 
39 | 디버깅을 해본 결과 상위 클래스에서 addll메서드에서 add를 호출하는데 여기서 add는 오버라이딩 된 add메서드를 결과적으로 3번 더 호출하게 됐습니다.</br>
40 | 추가로 다음 릴리즈에서 상위 클래스에 새로운 메서드를 추가했는데, 하필 하위 클래스에 추가한 메서드와 시그니처가 같고 반환 타입이 다를 경우 컴파일조차 되지 않습니다.</br>
41 | 이러한 문제점들은 컴포지션을 통해서 쉽게 피해갈 수 있습니다. 컴포지션은 기존 클래스를 확장하는 대신 새로운 클래스를 만들고 private 필드로 기존 클래스의 인스턴스를 참조해서 이용할 수 있습니다.
42 | <br>
43 | 
44 | 
45 | 상속은 클래스 B가 클래스 A와 **is-a** 관계일 때만 클래스 A를 상속해야 합니다.
46 |  클래스 B가 A를 상속하기 전에 B가 A인가? 자문해보고 "그렇다"라는 확신이 들지 않으면 **컴포지션(has-a)** 을 이용하는 게 좋습니다.
47 |  </br>
48 | 
49 | 컴포지션을 써야 할 상황에서 상속을 사용하는 건 내부 구현을 불필요하게 노출하는 꼴입니다. 그 결과 API가 내부 구현에 묶이고 그 클래스의 성능도 영원히 제한됩니다. 더 심각한 문제는 클라이언트가 노출된 내부에 **직접 접근**할 수 있다는 점입니다.
50 | </br>
51 | 컴포지션 대신 상속을 사용하기로 결정하면 마지막으로 자문해야 될 질문이 있습니다. "확장하려는 클래스의 API에 아무런 결함이 없는가" 결함이 있다면, 이 결함이 여러분 클래스의 API까지 전파돼도 괜찮은가?. 상속은 상위 클래스의 API를 그 결함까지도 그대로 승계합니다.
52 | </br>
53 | ### **정리**
54 | - 상속은 강력하지만 캡슐화를 해친다는 단점이 있습니다.
55 | - 상속은 상위 클래스와 하위클래스가 순수한 is-a 관계일 때만 사용해야합니다.
56 | - 상속의 단점을 피라려면 컴포지션을 활용합시다.


--------------------------------------------------------------------------------
/chap04/Item19.md:
--------------------------------------------------------------------------------
 1 | # [Item 19] 상속을 고려해 설계하고 문서화하라. 그렇지 않았다면 상속을 금지하라.
 2 | 
 3 | 여기서 말하는 **외부**란 프로그래머의 통제권 밖에 있어서 언제 어떤식으로 변경될지 모른다는 뜻입니다.
 4 | ### **상속을 고려한 문서화**
 5 | 1. 상속용 클래스는 재정의할 수 있는 메서드들은 내부적으로 어떻게 이용하는지 문서로 남겨야 합니다.
 6 | 2. 클래스의 내부 동작 과정 중간에 끼어들 수 있는 훅(hook)을 잘 선별하여 `protected`메서드 형태로 공개하는 것도 고려해보는 것도 좋습니다. (한편으로 너무 적게 노출해서 상속으로 얻는 이점을 없애지 않도록 주의해야 합니다.)
 7 | 3. 상속용으로 설계한 클래스는 배포 전에 반드시 하위 클래스를 만들어 **검증**해야 합니다.
 8 | 
 9 | ### 상속을 허용하는 클래스가 지켜야 할 제약
10 | 
11 | **상속용 클래스의 생성자는 직접적으로든 간접적으로든 재정의 가능 메서드를 호출해서는 안 됩니다**. 상위 클래스의생성자가 하위 클래스의 생성자보다 먼저 실행되므로 하위 클래스에서 재정의한 메서드가 하위 클래스의 생성자보다 먼저 호출됩니다. 
12 | </br>
13 | 상속을 금지하는 방법에는 두 가지 방법이 있습니다. 첫 번째는 클래스를 final으로 선언하는 것과 두번째는 모든 생성자를 private나 package-private로 선언하고 public 정적 팩터리를 만들어주는 방법입니다. 정적 팩터리 방법은 다양한 하위 클래스를 만들어 쓸 수 있는 유연성을 주며 이와 관련해서는 아이템 17에서 다뤘습니다.
14 | </br>
15 | ### 정리
16 | - 상속을 하려면 문서화를 해야 하며, 문서화 한 것은 반드시 지켜야 합니다.
17 | - 클래스를 확장해야 할 명확한 이유가 없으면 아이템 17에서 다뤘던 방식으로 상속을 금지합시다.
18 | 
19 | 


--------------------------------------------------------------------------------
/chap04/Item20.md:
--------------------------------------------------------------------------------
 1 | # [Item 20] 추상 클래스보다는 인터페이스를 우선하라.
 2 | 
 3 | 자바가 제공하는 다중 구현 메커니즘은 인터페이스와 추상 클래스가 있습니다. 자바8 부터는 인터페이스에서 **defualt moethod**를 제공할 수 있게 되어서 두 메커니즘 모두 인스턴스 메서드를 구현 형태로 제공할 수 있습니다.</br>
 4 | 추상 클래스와 인터페이스의 큰 차이점은 추상 클래스의 정의한 타입을 구현 클래스는 반드시 서브클래스가 된다는 점입니다. 자바에서는 단일 상속만 지원하기 때문에 이런 제약은 새로운 타입을 정의하는데 커다란 제약이 됩니다.</br></br>
 5 | 반면 인터페이스의 준수 사항을 잘 지키고 모든 메서드를 구현한 클래스는 어느 계층에 있든 인터페이스를 구현할 수 있습니다. 기존 클래스에도 손쉽게 새로운 인터페이스를 구현해 넣을 수 있습니다. 그저 인터페이스가 요구하는 메서드를 (아직 없다면) 추가하고, 클래스 선언에 `implements` 구문을 추가하면 됩니다.</br></br>
 6 | 반면 일반적으로 기존 클래스에 새로운 추상 클래스를 끼워넣는 일은 매우 간단합니다. 만약 두 클래스로 하나의 추상 클래스를 상속하길 원한다면, 그 추상 
 7 | 클래스는 계층구조상 두 클래스의 공통 조상이어야합니다. 
 8 | 이러한 방식은 클래스 계층구조에 커다란 혼란을 야기할 수 있습니다. 적절하지 않은 상황에서도 강제로 새로 추가된 추상 클래스의 모든 자손이 이를 상속하게 되는 것이다.</br>
 9 | 인테페이스는 **믹스인(mixin)** 정의에 안성맞춤입니다. 믹스인이란 클래스가 구현할 수 있는 타입으로, 믹스인을 구현한 클래스에 원래의 '주된 타입'외에도 특정 선택적 행위를 제공한다고 선언하는 효과를 줍니다. 예컨대 `Comparable`은 자신을 구현한 클래스의 인스턴스들끼리는 순서를 정할 수 있다고 선언하는 믹스인 인터페이스입니다. 이처럼 대상 타입의 주된 기능에 선택적 기능을 '혼합(mixed in)'한다고 해서 믹스인이라고 불립니다.</br>
10 | 반면 추상 클래스로는 믹스인을 정의할 수 없습니다. 기존 클래스에 덧씌울 수 없기 때문입니다. 클래스는 두 부모를 섬길 수 없고, 클래스 계층구조에는 믹스인을 삽입하기엔 합리적인 위치가 없기 때문입니다.
11 | 
12 | ### **인터페이스는 계층구조가 없는 타입 프레임워크 만들 수 있습니다.**
13 | ``` java
14 | public interface Singer {
15 |     AudioClip sing(Song s);
16 | }
17 | public interface Songwriter {
18 |     Song compose(int chartPosition);
19 | }
20 | ```
21 | 현실에는 계층을 엄격히 구분하기 어려운 개념이 있습니다. 위 코드처럼 타입을 인터페이스로 정의하면 가수 클래스가 `Singer`와 `SongWriter` **모두**를 구현해도 전혀 문제가 되지 않습니다.
22 | ``` java
23 | public interface SingerSongWriter extends Singer, Songwriter {
24 |     AudioClip strum();
25 | }
26 | ```
27 | 이런식으로 Singer와 Songwriter모두를 확장하고 새로운 메서드까지 추가한 제3의 인터페이스도 정의할 수 있습니다. 같은 구조를 클래스로 만드려면 속성이 n개라면 지원해야 할 조합의 수는 2^n개가 됩니다 이러한 현상을 **조합 폭발**(combinatorial explosion)이라고 부릅니다.
28 | </br></br>
29 | 인터페이스의 메서드 중 구현 방법이 명백한 것이 있다면, 그 구현을 디폴트 메서드로 제공하는 것도 방법입니다. 하지만 디폴트 메서드에도 제약이 있습니다. 많은 인터페이스가 `equals`와 `hashCode`같은 Object의 메서드를 정의하고 있지만, 이들은 디폴트 메서드로는 제공해서는 안 됩니다. 또하 인터페이스는 인스턴스 필드를 가질 수 없고 public이 아닌 정적멤버도 가질 수 없습니다. 마지막으로 여러분들이 만들지 않은 인터페이스에는 디폴트 메서드를 추가할 수 없습니다.</br>
30 | > 정리
31 | > - 일반적으로 다중 구현용 타입으로는 인터페이스가 적합합니다.
32 | > - 복잡한 인터페이스라면 구현하는 수고를 덜어주는 골격 구현을 함께 제공하는 방법도 고려하는걸 추천합니다.


--------------------------------------------------------------------------------
/chap04/Item21.md:
--------------------------------------------------------------------------------
 1 | # [Item 21] 인터페이스는 구현하는 쪽을 생각해 설계하라.
 2 | 
 3 | 자바 8 이전에는 기존 구현체를 깨뜨리지 않고 인터페이스에 새로운 메서드를 추가할 방법이 없었습니다. 자바8 부터는 디폴트 메서드를 제공해서 이러한 문제점들을 해결해줬지만 위험이 완전히 사라진 것은 아닙니다.
 4 | </br>
 5 | 
 6 | 자바 8이전까지는 인터페이스에 새로운 메소드가 추가될리 없다는 암묵적인 가정으로 작성되었습니다. 즉 디폴트 메서드는 구현한 클래스에 동의 없이 무작정 삽입되었습니다. 자바 8에서는 핵심 컬렉션 인터페이스들에 다수의 디폴트 메서드가 추가되었습니다.주로 **람다**를 활용하기 위해서입니다. 자바라이브러리의 디폴트 메서드는 코드 품질이 높고 범용적이라 대부분 잘 작동하지만, **생각할 수 있는 모든 상황에서 불변식을 해치지 않는 디폴트 메서드를 작성하기란 어려운 법입니다.**
 7 | 
 8 | ``` java
 9 |     default boolean removeIf(Predicate<? super E> filter) {
10 |         Objects.requireNonNull(filter);
11 |         boolean removed = false;
12 |         final Iterator<E> each = iterator();
13 |         while (each.hasNext()) {
14 |             if (filter.test(each.next())) {
15 |                 each.remove();
16 |                 removed = true;
17 |             }
18 |         }
19 |         return removed;
20 |     }
21 | ```
22 | 자바 8 `Collection` 인터페이스에 추가된 `removeIf` 메서드입니다. 이코드보다 더 범용적으로 구현하기도 어렵겠지만, 그렇다고 해서 현조하는 모든 Collection 구현체와 잘 어우러지는 것은 아닙니다.</br>
23 | 대표적인 예가 org.apache.commons.collections4.collection.SynchronizedCollection입니다. 이 클래스는 java.util.Collections.synchronizedCollction 정적 팩터리 메서드가 반환하는 클래스와 비슷합니다. 아파치 버전은 클라이언트가 제공한 객체로 락을 거는 능력을 추가로 제공합니다. 즉, 모든 메서드에 주어진 락 객체로 동기화한 후 내부 컬렉션 객체에 기능을 위임하는 래퍼 클래스입니다.</br>
24 | 아파치의 SynchronizedCollection는 removieIf 메서드를 재정의하고 있지 않습니다. 이 첵이 쓰여진 시점에는 removeIf를 재정의하고있지 않습니다. 이 클래스는 removeIf를 재정의 하고있지 않습니다. 그래서 이 클래스를 자바 8과 함께 사용하면 모든 메서드 호출을 알아서 동기화해주지 못합니다.</br>
25 | 자바 플랫폼 라이브러리에서도 이런 문제를 예방하기 위해 조치를 취했습니다. 예를 들어 구현한 인터페이스의 디폴트 메서드를 재정의하고, 다른 메서드에서는 디폴트 메서드를 호출하기 전에 필요한 작업을 수행하도록 했습니다.
26 | </br>
27 | 핵심은 인터페이스를 설계할 때는 세심한 주의를 기울여야 합니다. 디폴트 메서드로 기존 인터페이스에 새로운 메서드를 추가하면 커다란 위험도 딸려옵니다. 새로운 인터페이스라면 릴리즈 전에 반드시 테스트를 거쳐야 합니다.


--------------------------------------------------------------------------------
/chap04/Item22.md:
--------------------------------------------------------------------------------
 1 | # [Item 22] 인터페이스는 타입을 정의하는 용도로만 사용하라.
 2 | 
 3 | 인터페이스는 자신을 구현한 클래스의 인스턴스를 참조할 수 있는 타입 역할을 합니다. 그러므로 인터페이스를 구현한 클래스는 클라이언트에게 자신의 인스턴스로 무엇을 할 수 있는지 말해주는 것입니다. 인터페이스를 다른 용도로 사용하는 것은 부적절합니다.
 4 | </br>
 5 | 이 지침에 맞지 않는 예로 소위 상수 인터페이스라는 것이 있습니다. 상수 인터페이스는 메서드가 없이, 상수를 뜻하는 static final 필드로만 가득 찬 인터페이스를 뜻합니다.</br>
 6 | 
 7 | ``` java
 8 | public interface PhysicalConstants {
 9 |     static final double AVOGADROS_NUMBER =  6.022_140_857e34;
10 | 
11 |     static final double BOLTZMANN_CONSTANT = 1.380_648_52e-23;
12 | 
13 |     static final double ELECTRON_MASS = 9.109_383_56e-31;
14 | }
15 | ```
16 | 
17 | 상수 인터페이스 안티패턴은 인터페이스를 잘못 사용한 예입니다. 클래스 내부에서 사용하는 상수는 외부 인터페이스가 아니라 내부 구현에 해당합니다. 따라서 상수 인터페이스를 구현하는 것은 이 내부 구현을 클래스의 API로 노출하는 행위입니다. 클래스가 어떤 상수 인터페이스를 사용하든 사용자에게는 아무런 의미가 없습니다. 오히려 혼란을 줄 수가 있으며, 더 심각하게는 클라이언트 코드가 내부 구현에 해당하는 이 상수들에게 종속되게 합니다.
18 | </br>
19 | 그래서 다음 릴리즈에서 이 상수들을 더는 쓰지 않게 되더라도 바이너리 호환성을 위해 여전히 상수 인터페이스를 구현하고 있어야 합니다. final이 아닌클래스가 상수 인터페이스를 구현한다면 모든 하위 클래스의 네임스페이스가 그 인터페이스가 정의한 상수들로 오염되어 버립니다.
20 | </br>
21 | java.io.ObjectStreamConstants 등, 자바 플랫폼 라이브러리에도 상수 인터페이스가 몇 개 있으나, 인터페이스를 잘못 활용한 예이니 따라 해서는 안 됩니다. 상수를 공개할 목적이라면 더 합당한 방법들이 있습니다.
22 | </br>
23 | 특정 클래스나 인터페이스와 강하게 연관된 상수라면 그 클래스나 인터페이스 자체에 추가해야합니다. 대표적으로 `Integer`와 `Double`에 선언된 `MIN_VALUE`와 `MAX_VALUE` 상수가 이런 예입니다. 열거 타입으로 나타내기 적합한 상수라면 열거 타입으로 만들면 되고 그것도 아니라면 인스턴스화 할 수 없는 유틸클래스에 담아 공개하면 됩니다.
24 | 
25 | ``` java
26 | // 유틸리티 클래스
27 | 
28 | public class PhysicalConstants {
29 |     private PhysicalConstants()
30 | 
31 |     static final double AVOGADROS_NUMBER =  6.022_140_857e34;
32 | 
33 |     ... 생략
34 | }
35 | ```
36 | 
37 | ### 정리
38 | - 인터페이스는 타입을 정의하는 용도로만 사용해야 합니다, 실수 공개용 수단으로 사용하지 맙시다.


--------------------------------------------------------------------------------
/chap04/Item23.md:
--------------------------------------------------------------------------------
 1 | # [Item 23] 태그 달린 클래스보다는 클래스 계층구조를 활용하자.
 2 | 
 3 | 때때로 두 가지 이상의 의미를 표현하고 인스턴스의 특징을 알려주는 태그 필드로 나타내는 클래스를 본 적이 있을겁니다.
 4 | 
 5 | ### 안 좋은 예시
 6 | ``` java
 7 | public class Figure {
 8 | 
 9 |   enum Shape { RECTANGLE, CIRCLE };
10 | 
11 |   // 태그 필드 - 현재 모양을 나타냅니다.
12 |   final Shape shape;
13 | 
14 |   // 모양이 사각형(RECTANGLE)일 때만 쓰입니다.
15 |   double length;
16 |   double width;
17 | 
18 |   // 다음 필드 모양이 원(CIRCLE)일 때만 쓰입니다.
19 |   double radius;
20 | 
21 |   // 원 생성
22 |   Figure(double radius) {
23 |     shape = Shape.CIRCLE;
24 |     this.radius = radius;
25 |   }
26 | 
27 |   Figure(double length, double width) {
28 |     shape = Shape.RECTANGLE;
29 |     this.length = length;
30 |     this.width = width;
31 |   }
32 | 
33 |   double area() {
34 |     switch (shape) {
35 |       case RECTANGLE:
36 |         return length * width;
37 |       case CIRCLE:
38 |         return Math.PI * (radius * radius);
39 |       default:
40 |         throw new AssertionError();
41 |     }
42 |   }
43 | }
44 | ```
45 | 
46 | 태그 달린 클래스에는 단점이 많습니다. 열거 타입 선언, 태그 필드, switch문 등 잡다한 코드가 너무 많습니다. 여러 구현이 한 클래스에 있어서 구현도 나쁩니다. 인스턴스가 다른 특징에 속하는 관련없는 필드로 인해 메모리도 많이 사용하게 됩니다. 또 다른 의미를 추가하려면 switch문을 찾아 새 의미를 처리하는 코드를 추가해야하는 데 하나라도 빠뜨리면 문제가 될 수도 있습니다. 마지막으로, 인스턴스의 타입만으로는 현재 나타내는 의미를 알 길이 없습니다. 한 마디로 **태그 달린 클래스는 장황하고, 오류를 내기 쉽고, 비효율적입니다.**
47 | </br>
48 | 클래스 계층구조를 활용하는 **서브타이핑**을 이용해서 타입 하나로 다양한 의미의 객체를 표현할 수 있습니다. 태그 달린 클래스는 클래스 계층구조를 어설프게 흉내낸 아류일뿐입니다.
49 | </br>
50 | ### 태그달린 클래스를 클래스 계층 구조로 바꾸는 방법
51 | 1. 계층구조의 루트가 될 추상 클래스를 정의하고, 태그 값에 따라 동작이 달라지는 메서드들을 루트 클래스의 추상 메서드로 선언합니다.
52 | 2. 태그 값에 상관없이 동작이 일정한 메서드들을 루트 클래승 일반 메서드로 추가합니다.
53 | 3. 모든 하위 클래스에서 공통으로 사용하는 데이터 필드들도 전부 루트 클래스로 올립니다.
54 | 4. 루트 클래스를 확장한 구체 클래스를 의미별로 하나씩 정의합니다.
55 | 
56 | Figure 클래스에서는 태그 값과 상관없는 메서드가 하나도 없고, 모든 하위 클래스에서 사용하는 공통 데이터 필드가 없습니다. 그 결과 루트 클래스에는 추상메서드 area하나만 남게 됩니다.</br>
57 | 다음은 Figure 클래스를 계층구조 방식으로 구현한 코드입니다.
58 | ``` java
59 | abstract class Figure {
60 |   abstract double area;
61 | }
62 | 
63 | public class Circle extends Figure{
64 |   final double radius;
65 | 
66 |   public Circle(double radius) {
67 |     this.radius = radius;
68 |   }
69 | 
70 |   @Override
71 |   double area() {
72 |     return Math.PI * (radius * radius);
73 |   }
74 | 
75 | }
76 | 
77 | // Rentangle 클래스 위와 같은 방식으로 구현하면 됩니다.
78 | ```
79 | 태그 달린 클래스에 비교하면 쓸데 없는 코드들은 모두 제거했고, 각 의미를 독립된 클래스에 담아 관련 없던 데이터 필드를 모두 제거했습니다. 살아 남은필드들은 모두 final이며 각 클래스의 생성자가 모든 필드를 남김없이 초기화하고 추상 메서드를 구현했는지 컴파일러가 확인해줍니다.
80 | ### 정리
81 | - 태그 달린 클래스를 써야 하는 상황은 거의 없습니다.
82 | - 새로운 클래스를 작성할 때 태그 필드가 등자했다면 계층 구조롤 대체하는 방법을 고려해보자.
83 | - 기존 클래스가 필드를 사용하고 있다면 걔층구조로 리팩터링 하는 걸 고려민해보자.


--------------------------------------------------------------------------------
/chap04/Item24.md:
--------------------------------------------------------------------------------
 1 | # [Item 24] 멤버 클래스는 되도록 static으로 만들어라.
 2 | 
 3 | 중첩 클래스(nested class)는 자신을 감싼 바깥 클래스에서만 쓰어야 하며 그 이외 쓰임새가 있다면 톱레벨 클래스로 만들어야 합니다.
 4 | </br>
 5 | 중첩 클래스는 다음과 같이 네 종류로 나눌 수 있습니다.
 6 | - 정적 멤버 클래스
 7 | - (비정적)멤버 클래스
 8 | - 익명 클래스
 9 | - 지역 클래스
10 | 
11 | 이 중 정적 멤버 클래스를 제외한 나머지는 내부 클래스(inner class)에 해당합니다.
12 | ### 정적 멤버 클래스
13 | 정적 멤버 클래스는 다른 클래스 안에 선언되고, 바깥 클래스의 private 멤버에도 접근할 수 있다는 점만 제외하고는 일반 클래스외 똑같습니다. 정적 멤버 클래스는 흔히 바깥 클래스와 함께 쓰일 때만 유용한 public 도우미 클래스로 쓰입니다.
14 | ### 비정적 멤버 클래스
15 | 비정적 멤버 클래스의 인스턴스 바깥 클래스의 인스턴스와 암묵적으로 연결됩니다. 그래서 비정적 멤버 클래스의 인스턴스는 메서드에서 정규화된 this를 사용해 바깥 인스턴스의 메서드를 호출하거나 바깥 인스턴스의 참조를 가져올 수 있습니다. </br>
16 | 여기서 말하는 정규화된 this란 **클랴스명.this** 형태로 바깥 클래스의 이름을 명시하는 용법을 말합니다. 따라서 바깥 인스턴스와 독립적으로 존재할 수 있다면 정적 멤버 클래스로 만들어야 합니다. 비정적 멤버 클래스는 바깥 인스턴스 없이 생성할 수 없기 때문입니다.
17 | </br> 
18 | 바깥 클래스의 인스턴스 메서드에 비정적 멤버 클래스의 생성자를 호출할 때 자동으로 만들어지는 게 보통이지만, 드물게 직접 바깥 인스턴스의 클래스.new MemberClass()를 호출해 수동으로 만들기도 하지만 비정적 멤버 클래스의 인스턴스 안에 만들어져 메모리 공간을 차지하며, 생성 시간도 더 걸립니다.
19 | </br>
20 | 비정적 멤버 클래스는 **어댑터**를 정의할 때 자주 사용됩니다. 즉 어떤 클래스의 인스턴스를 감싸 마치 다른 클래스의 인스턴스처럼 보이게 하는 뷰로 사용됩니다. 예컨대 `Map` 인터페이스의 구현체들은 보통 (keySet, entrySet 메서드가 반환하는) 자신의 컬렉션 뷰를 구현할 때 비정적 멤버 클래스를 사용합니다.
21 | </br>
22 |  **멤버 클래스에서 바깥 인스턴스에 접근할 일이 없다면 무조건 static을 붙여서 정적 멤버 클래스로 만듭시다**. static을 생략하면 바깥 인스턴스로의 숨은 외부 참조를 갖게 됩니다. 이렇게 되면 시간과 공긴이 소비되고 더 심각한 문제는 가비지 컬렉션이 바깥 클래스의 인스턴스를 수거하지 못하는 메모리 누수가 생길 수 있습니다.
23 | 
24 |  ### 익명 클래스
25 |  익명 클래스는 바깥 클래스의 멤버가 아닙니다. 멤법와 달리, 쓰이는 시점에 선언과 동시에 인스턴스로 만들어집니다. 그리고 오직 비정적인 문맥에서 사용될 때만 바깥 클래스의 인스턴스를 참조할 수 있으며 instance of검사나 클래스의 이름이 필요한 작업은 수행할 수 없습니다.</br>
26 |  자바가 람다를 지원하기 전에는 즉석에서 작은 함수 객체나 처리 객체(process object)를 만드는 데 만드는 데 익명 클래스를 주로 사용했으며 또 정적 팩터리 메서드를 구현할 때입니다.
27 |  ### 지역 클래스
28 |  지역 클래스는 네 가지 중첩 클래스 중 가장 드물게 사용됩니다. 지역 클래스는 지역 변수를 선언할 수 있는 곳이면 실직적으로 어디서든 선언할 수 있고, 유효범위도 지역변수와 같습니다.
29 | 
30 |  ### 정리
31 |  - 중첩 클래스에는 네 가지가 있으며, 각각의 쓰임이 다릅니다.
32 |  - 메서드 밖에서도 사용해야 하거나 메서드 안에 정의하기엔 너무 길다면 멤버 클래스로 만듭니다.
33 |  - 멤버 클래스의 인스턴스 각각이 바깥 인스턴스를 참조한다면 비정적으로. 그렇지 않으면 정적으로 만듭시다.
34 |  - 중첩 클래스가 한 메서드 안에서만 사용되며 그 인스턴스를 생선하는 지점이 단 한 곳이고 해당 타입으로 쓰기에 적합한 클래스나 인터페이스가 있다면 익명 클래스로 만들고, 그렇지 않으면 지역 클래스로 만듭시다.
35 | 


--------------------------------------------------------------------------------
/chap04/Item25.md:
--------------------------------------------------------------------------------
 1 | # [Item 25] 톱레벨 클래스는 한 파일에만 담으라
 2 | ``` java
 3 | public class Main {
 4 |     public static void main(String[] args) {
 5 |         System.out.println(Utensil.NAME + Dessert.NAME);
 6 |     }
 7 | }
 8 | ```
 9 | 위 코드의 소스 파일은 Main 클래스 하나를 담고 있고, Main 클래스는 다른 톱레벨 클래스 2개(Utensil과 Dessert)를 참조합니다.
10 | </br>
11 | `Utensil`와 `Dessert` 클래스가 **Utensil.java**라는 한 파일에 정의되어 있다고 가정해봅시다. 
12 | ``` java
13 | class Utensil {
14 |     static final String NAME = "pan";
15 | }
16 | class Dessert {
17 |     static final String NAME = "cake";
18 | }
19 | ```
20 | Main을 실행하면 pancake가 출력됩니다.
21 | </br> 
22 | 이제 두 클래스를 담은 **Dessert.java**라는 파일을 만들었다고 가정해봅시다.
23 | ``` java
24 | class Utensil {
25 |     static final String NAME = "pot";
26 | }
27 | class Dessert {
28 |     static final String NAME = "pie";
29 | }
30 | ```
31 | 컴파일러는 가장 먼저 Main.java를 컴파일하고, 그 안에서 (Dessert 참조보다 먼저 나오는) Utensil 참조를 만나면 Utensil.java 파일을 살펴 Utensil과 Dessert를 모두 찾아낼 것입니다. 그런 다음 컴파일러가 두 번째 명령줄 인수로 넘어온 Dessert.java를 처리하려 할 때 같은 클래스의 정의가 이미 있음을 알게 됩니다.
32 | </br>
33 | 한편 javac Main.java나 javac Main.java Utensil.java 명령으로 컴파일하면 Dessert.java 파일을 작성하기 전처럼 pancake를 출력합니다. 그러나 javac Dessert.java Main.java 명령으로 컴파일하면 potpie를 출력합니다. 이처럼 컴파일러에 어느 소스 파일을 먼저 건네느냐에 따라 동작이 달라지므로 반로 잡아야할 문제입니다. 다행히 해결책은 간단합니다. 단순힌 톱레벨 클래스들을 서로 다른 소스 파일로 분리하면 그만입니다.
34 | </br>
35 | 굳이 여러 톱레벨 클래스를 한 파일에 담고 싶다면 정적 멤버 클래스를 사용하는 방법을 고민해볼 수 있습니다.
36 | ``` java
37 |   public class Test {
38 |     public static void main(String[] args) {
39 |            System.out.println(Utensil.NAME + Dessert.NAME);
40 |     }
41 |     private static class Utensil {
42 |            static final String NAME = "pan";
43 |     }
44 |     private static class Dessert {
45 |            static final String NAME = "cake";
46 |     } 
47 | }
48 | 
49 | ```
50 | 


--------------------------------------------------------------------------------
/chap05/Item26.md:
--------------------------------------------------------------------------------
 1 | # [Item 26] Raw 타입은 사용하지 마라.
 2 | 
 3 | `raw type`이란 제네릭 타입에서에서 타입 파라미터를 전혀 사용하지 않았을 때를 말합니다.
 4 | ``` java
 5 | // raw type
 6 | List list = new ArrayList();
 7 | ```
 8 | 로 타입은 타입 선언에서 제네릭 타입 정보가 전부 지워진 것처럼 동작하는데, 제네릭이 도래하기 전 코드와 호환성을 위해서 주로 존재합니다.</br>
 9 | ``` java
10 | // 문자열을 저장하는 컬렉션
11 | private final List names = new ArrayList();
12 | ```
13 | 위 코드를 사용하면 String대신 다른 타입을 넣어도 오류없이 실행됩니다. (경고 메세지를 보여주긴 합니다.)
14 | ``` java
15 | naems.add(1); // "Unchecked call" 경고를 보여줍니다.
16 | ```
17 | ``` java
18 | String str = (String) names.get(0); // ClassCastException
19 | ```
20 | 컴파일 오류를 체크하지 못하고 런타임할 때 예외가 발생하게 됩니다. 가장 이상적인 오류는 컴파일할 때 발견하는 것이 좋습니다. 이렇게 되면 런타임에 문제를 겪는 코드와 원인을 제공한 코드가 물리적으로 상당히 떨어져 있을 가능성이 커집니다.
21 | </br>
22 | 제네릭을 활용하면 이 정보가 주석이 아닌 타입 선언 자체에 녹아듭니다.
23 | ``` java
24 | // 매개변수화된 컬렉션 타입 - 타입 안전성 확보
25 | private final List<String> names = new ArrayList<>();
26 | ```
27 | 
28 | 이렇게 선언하면 컴파일러는 names에는 String만 넣어야 함을 컴파일러가 인지하게 됩니다. 이제 names에 엉뚱한 타입의 인스턴스를 넣으려고하면 컴파일 오류가 발생합니다.
29 | ``` java
30 | names.add(1); // 컴파일 오류
31 | ```
32 | 앞에서도 얘기했듯, 로 타입(타입 매개변수가 없는 제네릭 타입)은 절대로 사용해서는 안 됩니다. **로 타입을 쓰면 제네릭이 안겨주는 안전성과 표현력을 모두 잃게 됩니다.** 로 타입을 만들어놓은 이유는 호환성 때문입니다. 자바가 제네릭을 받아들이기까지 거의 10년이 걸린 탓에 제네릭 없이 짠 코드를 모두 수용하면서 제네릭을 사용하는 새로운 코드와도 맞물려 돌아가게 해야만 했습니다.</br>
33 | 
34 | ### List vs List\<Objects>
35 | 로 타입 List는 제네릭 타입에서 완전히 발을 뺀 것이고, List\<Object>는 모든 타입을 허용한다는 의사를 컴파일러에게 전달한 것입니다. 매개변수로 List를 받는 메서드에 List\<String>를 넘길 수 있지만, List\<Object>를 받는 메서드에는 List\<String>를 넘길 수 없습니다. 이는 제네릭의 하위 타입 규칙 때문입니다.</br>
36 | 즉, List\<Integer>는 로 타입인 List의 하위타입 이지만, List\<Object>의 하위타입은 아닙니다. 그 결과 List\<Object>같은 매개변수화 타입을 사용할 때와 달리 List같은 로 타입을 사용하면 타입 안전성을 잃게 됩니다.
37 | </br>
38 | 
39 | 예제를 위한 코드
40 | 
41 | ``` java
42 | // Interger는 Number의 서브 타입입니다.
43 | List<Integer> intList = new ArrayList<>();
44 | List<Number> numberList = intList; // 컴파일 에러
45 | ```
46 | 
47 | ``` java
48 | List<Integer> intList = new ArrayList<>();
49 | List rawType = intList; // 오류가 발생하지 않지만, 안전하지 않습니다.
50 | ```
51 | 이쯤 되면 원소의 타입을 몰라도 되는 로 타입을 쓰고 싶어질 수 있습니다. 그럴 땐 비한정적 와일드 타입(unbounded wildcard types)를 사용하는 대안이 있습니다. 이는 타입 파리머티에 `?`을 작성하면 됩니다.
52 | 
53 | ``` java
54 | // unbounded wildcard type - 타입 세이프하고 유연합니다,
55 | static int numElementsInCommon(Set<?> s1, Set<?> s2) { ... }
56 | ```
57 | 
58 | 그렇다면 비한정적 와일드카드 타입인 Set\<?>와 로타입인 Set의 차이는 무엇일까? 물음펴가 무언가 멋진 일은 해주는 것일까?</br>
59 | 와일드 카드는 type safe 하고 로 타입은 그렇지 않다는 점입니다. 로 타입 원소에는 아무 원소나 넣을 수 있으니 타입 붋변식을 훼손하기 쉽습니다. </br>
60 | 반면 Collection\<?>에는 (null 이외는) 어떤 원소도 넣을 수 없습니다. 다른 원소를 넣으려 하면 컴파일 할 때 오류 메세지를 보여줍니다. 이러한 제약을 받아들일 수 없다면 제네릭 메서드나 **bounded wildcard type**을 사용하면 됩니다.</br>
61 | 로 타입을 쓰지 말라는 규칙에도 소소한 예외가 몇 개 있습니다. **class 리터럴에는 로 타입을 써야 합니다. 자바 명세는 class 리터럴에 매개변수화 타입을 사용하지 못하게 했습니다.**(배열과 기보 타입은 허용합니다)</br>
62 | 예를 들어 List.class.String[].class, int.class는 허용하고 List\<String>.class와 List\<?>.class는 허용하지 않습니다.
63 | </br>
64 | 두 번째 예외는 instanceof 연산자와 관련이 있습니다. 런타임에는 제네릭 타입 정보가 지워지므로 instanceof 정보가 지워지므로 instanceof 연산자는 비한정적 와일드카드 타입 이외의 매개변수화 타입에는 적용할 수 없습니다.
65 | </br>
66 | ### 정리
67 | - 로 타입을 사용하면 런타임 예외가 일어날 수 있으니 사용하면 안 됩니다.
68 | - 로 타입은 제네릭이 도입되기 이전 코드와의 호환성을 위해 제공될 뿐입니다.
69 | - Set\<Object>는 어떤 타입의 객체도 저장할 수 있는 매개변수화 타입입니다.
70 |   
71 | 


--------------------------------------------------------------------------------
/chap05/Item27.md:
--------------------------------------------------------------------------------
 1 | # [Item 27] 비검사 경고를 제거하라.
 2 | 
 3 | 제네릭에 관련된 수 많은 컴파일 경고들이 있습니다. 비검사 형변환 경고, 비검사 메서드 호출 경고, 비검사 매개변수화 가변인수 타입 경고, 비검사 변환 경고 등이 있습니다. 제네릭에 익숙해질 수록 마주치는 경고 수는 줄어들겠지만 새로 작성한 코드가 한 번에 깨끗하게 컴파일되리라 기대하지는 맙시다.</br>
 4 | 대부분의 비검사 경고는 쉽게 제거할 수 있습니다. 코드를 다음처럼 잘못 작성했다고 예시를 들어봅시다.
 5 | ``` java
 6 | Set<Fruits> fruits = new Hashset();
 7 | ```
 8 | 그러면 컴파일러는 무엇이 잘못 됐는지 설멸해 줄 것입니다(javac 명령줄 인수에 -Xlint:unchecked 옵션을 추가해야 합니다)
 9 | </br>
10 | 컴파일러가 알려준 대로 수정하면 경고가 사라집니다. 자바 7부터는 컴파일러가 알려준 타입 매개변수로 명시하지 않아도 타입 추론을 지원합니다.
11 | ``` java
12 | Set<Fruits> fruits = new Hashset<>();
13 | ```
14 | 할 수 있는 한 모든 비검사 경고를 제거합시다. 모두 제거한다면 그 코드는 타입 안전성이 보장됩니다. 경고를 제거할 수는 없지만 타입이 안전하다고 확신이 들 때는 **@SuppressWarning("unchecked")** 애너테이션을 달아 경고를 숨깁시다. @SuppressWarning 애너테이션은 개별 지역번수 선언부터 클래스 전체까지 어떤 선언에도 달 수 있습니다. 하지만 가능한 좁은 범위에 적용하는 게 좋습니다.</br>
15 | 자칫 심각한 경고를 놓칠 수 있으니 절대로 클래스 전체에 적용해서는 안 됩니다. @SuppressWarning("unchecked") 애너테이션을 사용할 때면 그 경고를 무시해도 안전한 이유를 항상 주석으로 남겨야 합니다.
16 | ### 정리
17 | - 비검사 경고는 중요하니 무시하지 말자. 모든 비검사 경고는 런타임에 ClassCastException을 일으킬 수 있는 잠재적 가능성이 있습니다.
18 | - 경고를 없앨 방법을 찾지 못했다면, 그 코드의 안전함을 증명하고 가능한 범위를 좁혀서 @SuppressWarning("unchecked") 애노테이션으로 경고를 숨깁시다.


--------------------------------------------------------------------------------
/chap05/Item28.md:
--------------------------------------------------------------------------------
 1 | # [Item 28] 배열보다는 리스트를 사용하라.
 2 | 
 3 | ### 배열과 제네릭 타입의 차이
 4 | 첫번째 차이점. 배열은 공변 입니다. 어려워 보이는 단어지만 뜻은 간단합니다. Sub가 Super의 하위 타입이라면 배열 Sub[]는 배열 Super[]의 하위 타입이 됩니다.</br>
 5 | 반면, 제네릭은 불공변입니다. 즉 서로 다른 타입 Type1과 Type2가 있을 때, List<Type1>은 List<Type2>의 하위 타입도 아니고 상위 타입도 아닙니다.
 6 | 이것만 보면 제네릭에 문제가 있다고 생각할 수 있지만, 사실 문제가 있는 건 배열 쪽입니다. 다음은 문법상 허용되는 코드입니다.
 7 | ``` java
 8 | // 런타임 에러
 9 | Object[] objectArray = new Long[1];
10 | objectArray[0] = "타입이 달라 넣을 수 없다."; // 런타임시 ArrayStoreException을 던진다
11 | ```
12 | ``` java
13 | // 컴파일 에러
14 | List<Object> ol = new ArrayList<Long>(); // 호환되지 않는 타입
15 | ```
16 | 어느 쪽이든 Long용 저장소에 String을 넣을 수 없습니다. 다만 배열 같은 경우 런타임에야 알 수 있고, 리스트는 컴파일 시에 알아챌 수 있어서 더 좋습니다.
17 | </br>
18 | 두번째 차이점. 배열은 실체화(reify)됩니다. 무슨 뜻이냐면 배열은 런타임에도 자신이 담기로 한 원소의 타입을 인지하고 확인합니다. 그래서 위 코드에서 Long배열에 String을 넣으려 하면
19 | ArrayStoreException이 발생합니다. 반면 제네릭은 타입 정보가 런타임에는 소거(erasure)됩니다.</br>
20 | 원소 타입을 컴파일타임에만 검사하며 런타임에는 알 수 조차도 없다는 뜻입니다. 소거는 제네릭 지원되기 전의 레거시 코드와 제네릭 타입을 함께 사용할 수 있게 해주는 메커니즘으로, 자바 5가 제네릭으로 순조롭게 전환될 수 있도록 해주었습니다.
21 | </br>
22 | 이상의 주요 차이로 인해 배열과 제네릭은 잘 어울러지지 못합니다. 예컨대 배열은 제네릭 타입, 매개변수화 타입, 타입 매개변수로 사용할 수 없습니다. 즉 코드를 new List<E>[], new List<String>[], new E[] 식으로 작성하면 컴파일할 때 제네릭 배열 생성 오류를 일으킵니다.</br>
23 | 
24 | ### 제네릭 배열을 만들지 못하게 막은 이유
25 | 타입이 안전하지 않기 때문입니다. 이를 허용하면 컴파일러가 자동 생성한 형변환 코드에서 런타임에 **ClassCaseException**이 발생할 수 있습니다. 런타임에 ClassCaseException이 발생하는 일을 막아주겠다는 제네릭 타입 시스템의 취지에 어긋나는 것입니다.
26 | ``` java
27 | // 컴파일 되지 않는다.
28 | List<String>[] stingLists = new List<String>[1]; // (1)
29 | List<Integer> intList = List.of(42);            // (2)
30 | Object[] objects = stingLists;                   // (3)
31 | Object[0] = intList;                            // (4)
32 | String s = stingLists[0].get(0);                 // (5)
33 | ```
34 | 제네릭 배열을 생성하는 (1)이 허용된다고 가정해봅시다. (2)는 원소 하나인 List<Integer>를 생성합니다. (3)은 (1)에서 생성한 List<String>의 배열을 Object 배열에 할당합니다.
35 | 배열은 공변이니 아무 문제가 없습니다. (4)는 (2)에서 생성한 List<Integer>의 인스턴스를 Object 배열의 첫 원소로 저장합니다. 제네릭은 소거 방식으로 구현되어서 이 역시 성공합니다. 즉, 런타임에는 List<Integer> 소거 방식으로 이 역시 소거됩니다. 즉 런타임에는 List<Integer>안스턴스의 타입은 단순히 List가 되고, List<Integer>[] 인스턴스의 타입은 List[]가 됩니다. 따라서 (4)에서도 ArrayStoreException을 발생시키지 않습니다.</br>
36 | 문제는 List<String>인스턴스만 담겠다고 선언한 stingLists 배열에는 지금 List<Inrteger> 인스턴스가 저장돼 있습니다. 결국 (5)에서 ClassCaseExceptionn이 발생하게 됩니다.
37 | 이런 일을 방지하려면 (제네릭 배열이 생성되지 않도록) (1)에서 컴파일 오류를 발생해야 합니다.
38 | </br>
39 | E, List<E>, List<String> 같은 타입을 실체화 불가 타입(non-reifiable type)이라 합니다. 쉽게 말하자면, 실체화되지 않아서 런타임에는 컴파일타임보다 타입 정보를 적게 가지는 타입입니다. 소거 메커니즘 때문에 매개변수화 타입 가운데 실체화될 수 있는  타입은 List<?>와 Map<?, ?>같은 비한정적 와일드카드 타입뿐입니다. 배열을 비한정적 와일드카드 타입으로 만들 수는 있지만, 유용하게 쓰일 일은 별로 없습니다.
40 | </br>
41 | 
42 | ### 정리
43 | - 배열은 공변이고 실체화가 되지만 제네릭은 불공변이고 타입 정보가 소거됩니다.
44 | - 배열은 런타임에는 타입 안전하지만 컴파일타임에는 그렇지 않습니다.
45 | 
46 | 


--------------------------------------------------------------------------------
/chap05/Item29.md:
--------------------------------------------------------------------------------
 1 | # [Item 29] 이왕이면 제네릭 타입으로 만들라.
 2 | 
 3 | Item 7에서 다루었던 스택 코드를 제네릭으로 변형한 코드입니다.
 4 | ```java
 5 | public class Stack<E> {
 6 |   private E[] elements;
 7 |   private int size = 0;
 8 |   private static final int DEFAULT_INITIAL_CAPACITY = 16;
 9 | 
10 |   public Stack() {
11 |     elements = (E[]) new Object[DEFAULT_INITIAL_CAPACITY]; // 경고 메세지 타입이 안전하지 않음
12 |   }
13 | 
14 |   public void push(E e) {
15 |     ensoureCapaciy();
16 |     elements[size++] = e;
17 |   }
18 | 
19 |   public E pop() {
20 |     if (size == 0) {
21 |       throw new EmptyStackException();
22 |     }
23 |     E result = elements[--size];
24 |     elements[size] = null;
25 |     return result;
26 |   }
27 |   ... 중략
28 | }
29 | ```
30 | 컴파일러는 이 프로그램이 안전한지 증명할 방법은 없지만, 우리는 할 수 있는 한 이 비검사 형변환이 프로그램의  타입 안전성을 해치지 않는지 스스로 확인해야합니다.
31 | </br>
32 | 비검사 형변환이 안전하다는 걸 확인했다면 범위를 최소로 좁혀 @SuppressWarnings("unchecked")를 이용하여 해당 경고를 숨깁시다.
33 | ``` java
34 | // 배열 elements는 push(E)로 넘어온 E 인스턴스만 담는다.
35 | // 따라서 타입 안전성을 보장하지만
36 | // 이 배열의 런타임 타입은 E[]가 아닌 Object[]입니다.
37 | @SuppressWarnings("unchecked")
38 | public Stack() {
39 |   elements = (E[]) new Object[DEFAULT_INITIAL_CAPACITY];
40 | }
41 | ```
42 | 위 방법 말고 다른 방식으로는 elements 필드의 타입을 E[]에서 Object[]로 바꾸는 것입니다. 이렇게 하면 pop메서드 부분을 다음과 같이 수정해줘야 합니다.
43 | ``` java
44 | E result = (E) elements[--size];
45 | ```
46 | E는 실체화 불가 타입이므로 컴파일러는 런타임에 이뤄지는 형변환이 안전한지 증명할 방법이 없습니다. 이번에도 직접 증명하고 경고를 숨길 수 있습니다.
47 | ``` java
48 | @SuppressWarnings("unchecked")
49 | E result = (E) elements[--size];
50 | ```
51 | 첫 번째 방식은 형변환을 배열 생성시 단 한 번만 해주면 되지만, 두 번째 방식에서는 배열에서 원소를 읽을 때마다 해줘야하므로 첫 번째 방식이 더 자주 사용됩니다. 하지만
52 | (E가 Object가 아닌 한) 배열의 런타임 타입이 컴파일타임 타입과 달라 힙 오염을 일으킵니다.</br>
53 | 사실 제네릭 타입 안에서 리스트를 사용하는 게 항상 가능하더라도, 꼭 더 좋은 건 아닙니다. 자바가 리스트를 기본 타입으로 제공하지 않으므로 ArrayList같은 제네릭 타입도 결국은 기본 타입인 배열을 사용해 구현해야 합니다. 또한 HashMap 같은 제네릭 타입은 성능을 높일 목적으로 배열을 사용하기도 합니다.
54 | ### 정리
55 | - 클라이언트에서 직접 형변환해야 하는 타입보다 제네릭 타입이 더 안전하고 쓰기 편합니다.
56 | - 새로운 타입을 설계할 때는 형변환 없이도 사용할 수 있도록 합시다.
57 | - 기존 타입 중 제네릭이었어야 하는 게 있다면 제네릭 타입으로 변경합시다.
58 | 
59 | 
60 | 


--------------------------------------------------------------------------------
/chap05/Item30.md:
--------------------------------------------------------------------------------
 1 | # [Item 30] 이왕이면 제네릭 메서드로 만들라
 2 | 
 3 | 제네릭 메서드는 대표적으로 `Collections`의 알고리즘 메서드(binarySearch, sort등)가 있습니다. 사용 방법은 리턴타입 앞에다 타입을 명시해주면 됩니다. 다음은 두 집합의 합집합을 반환하는 문제가 있는 메서드입니다.
 4 | ``` java
 5 | // raw tyoe 사용 - 수용 불가
 6 |   public static Set union(Set s1, Set s2) {
 7 |     Set result = new HashSet(s1);
 8 |     result.addAll(s2);
 9 |     return result;
10 |   }
11 | ```
12 |  컴파일은 되지만 경고가 발생합니다. 경고를 없애려면 이 메서드 타입을 안전하게 만들어야 합니다. 다음 코드에서 타입 매개변수 목록은 <E>이고 반환 타입은 Set<E>입니다.
13 |  ``` java
14 |    public static <E> Set<E> union(Set<E> s1, Set<E> s2) {
15 |     Set<E> result = new HashSet<>(s1);
16 |     result.addAll(s2);
17 |     return result;
18 |   }
19 |  ```
20 |  다음 코드는 이 메서드를 사용하는 프로그램입니다. 직접 형변환 하지 않아도 어떤 오류나 경고 없이 컴파일 됩니다.
21 | ``` java
22 | public static void main(Sting[] args) {
23 |     Set<String> guys = Set.of("pual", "jin");
24 |     Set<String> stooges = Set.of("jerry", "sia");
25 |     Set<String> aflCio = union(guys, stooges);
26 |     System.out.println(aflCio);
27 | }
28 | ```
29 | 이를 한정적 와일드카드 타입을 사용하면 더 유연하게 개선할 수 있습니다.
30 | </br>
31 | 제네릭은 런타임에 타입 정보가 소거되므로 하나의 객체를 어떤 타입으로든 매개변수화 할 수가 있습니다. 하지만 이렇게 하려면 요청한 타입 매개변수에 맞게 매번 그 객체의 타입을 바꿔주는 정적 팩터리를 만들어야 합니다. 이 패턴을 제네릭 싱글턴 팩터티라 하며, Collections.reverseOrder 같은 함수 객체나 Collections.emptySet 같은 컬렉션용으로 사용합니다.
32 | </br>
33 | 이번에는 항등함수를 담은 클래스를 만들고 싶다고 해봅시다. 자바 라이브러리의 Function.idenify를 사용해도 되지만 직접 작성해 보겠습니다. 항등함수 객체는 상태가 없으니 요청할 때마다 새로 생성하는 것은 낭비입니다. 자바의 제네릭이 실체화된다면 항등함수를 타입별로 하나씩 만들어야 했겠지만, 소거 방식을 사용한 덕에 제네릭 싱글턴 하나면 충분합니다.
34 | 
35 | ``` java
36 |   private static UnaryOperator<Object> IDENTIFY_FN = (t) -> t;
37 | 
38 |   @SuppressWarnings("unchecked")
39 |   public static <T> UnaryOperator<T> identifyFunction() {
40 |     return (UnaryOperator<T>) IDENTIFY_FN; 
41 |   }
42 | ```
43 | T가 어떤 타입이든 UnaryOperator<T>를 사용해도 type safe합니다. </br>
44 | 상대적으로 드물긴 하지만 자기 자신이 들어간 표현식을 사용하여 타입 매개변수의 허용 범위를 한정할 수 있습니다. 바로 재귀적 타입 한정이라는 개념입니다. 주로 타입의 자연적 순서를 정하는 `Comparable` 인터페이스와 함께 쓰입니다.
45 | 
46 | ``` java
47 | public interface Comparable<T> {
48 |     int compareTo(T o);
49 | }
50 | ```
51 | 타입 매개변수 T는 `Comparable<T>`를 구현한 타입이 비교할 수 있는 원소의 타입을 정의합니다. 실제로 거의 모든 타입은 자신과 같은 타입의 원소와만 비교할 수 있습니다. 따라서 String은 Comparable<String>을 구현하고 Integer는 Comparable<Integer>를 구현한 식입니다.
52 | 
53 | ``` java
54 | public static <E extends Comparable<E>> E max(Collection<E> c);
55 | ```
56 | 타입 한정인 <E extends Comparable<E>>는 "모든 타입 E는 자신과 비교할 수 있다"라고 해석할 수 있습니다.
57 | </br>
58 | 다음은 방금 선언한 메서드의 구현입니다. 컬렉션에 담긴 원소의 자연적 순서를 기준으로 최댓값을 계산하며, 컴파일 오류나 경고는 발생하지 않습니다.
59 | 
60 | ``` java
61 |   public static <E extends Comparable<E>> E max(Collection<E> c) {
62 |     if (c.isEmpty()) {
63 |       throw new IllegalArgumentException("컬렉션이 비어 있습니다.");
64 |     }
65 | 
66 |     E result = null;
67 |     for (E e : c) {
68 |       if (result == null || e.compareTo(result) > 0) {
69 |         result = Objects.requireNonNull(e);
70 |       }
71 |     }
72 |     return result;
73 |   }
74 | ```
75 | ### 정리
76 | - 제네릭 타입과 마찬가지로, 클라이언트에서 입력 매개변수와 반환값을 명시적으로 형변환해야 하는 메서드보다 제네릭 메서드가 더 안전하며 사용하기도 쉽습니다.


--------------------------------------------------------------------------------
/chap05/Item31.md:
--------------------------------------------------------------------------------
  1 | # [Item 31] 한정적 와일드카드를 사용해 API 유연성을 높여라
  2 | 
  3 | 때론 불공변 방식보다 유연한 무언가가 필요할 때가 있습니다. 아이템 29의 Stack 클래스를 떠올려보면
  4 | 
  5 | ``` java
  6 | public class Stack<T> {
  7 |     public Stack();
  8 |     public void push (E e);
  9 |     public E pop();
 10 |     public boolean isEmpty();
 11 | }
 12 | ```
 13 | 여기서 일련의 원소를 스택에 넣는 메서드를 추가한다고 하면
 14 | ``` java
 15 | public void pushAll(Iterable<E> src) {
 16 |     for (E e : src) {
 17 |         push(e);
 18 |     }
 19 | }
 20 | ```
 21 | Iterable src의 원소 타입의 스택의 원소 타입과 일치하면 잘 작동합니다. 하지만 Stack<Number>로 선언한 후 pushAll(intVal)을(Iteger 타입) 호출하면 오류가 뜹니다. 매개변수 타입이 불공변이기 떄문입니다.</br>
 22 | 이러한 상황에서는 한정된 와일드카드(unbounded wildcard)를 이용해서 해결할 수 있습니다. pushAll의 입력 매개변수 타입은 'E의 iterable'이 아니라 'E의 하위타입 Iterable'이어야 하며, 와일드 카드 Iterable<? extends E>가 정확히 이런뜻입니다.
 23 | ``` java
 24 | public void pushAll(Iterable<? extends E> src) {
 25 |     for (E e : src) {
 26 |         push(e);
 27 |     }
 28 | }
 29 | ```
 30 | 위와 같이 수정할 수 있습니다. 이번에는 popAll 와일드카드 타입을 사용하지 않은 메서드를 작성해 보겠습니다.
 31 | 
 32 | ``` java
 33 | // 와을드카드 타입을 사용하지 않은 메서드 - 결함이 있습니다.
 34 | public void popAll(Collection<E> dst) {
 35 |     while (!isEmpty()) {
 36 |         dst.add(pop());
 37 |     }
 38 | }
 39 | ```
 40 | 
 41 | ``` java
 42 | Stack<Number> numberStack = new Stack<>();
 43 | Collection<Object> objects = ...;
 44 | numberStack.popAll(objects);
 45 | ```
 46 | 컴파일 하면 "Collection<Object>는 Collection<Nummber>의 하위 타입이 아니다"라는 오류가 발생합니다. 이번에는 반대로 'E의 Collection'이 아니라 'E의 상위 타입의 Collection'이어야 합니다.
 47 | 
 48 | ``` java
 49 | // 와을드카드 타입을 사용하지 않은 메서드 - 결함이 있습니다.
 50 | public void popAll(Collection<E super E> dst) {
 51 |     while (!isEmpty()) {
 52 |         dst.add(pop());
 53 |     }
 54 | }
 55 | ```
 56 | 위와 같이 수정할 수 있습니다. 메세지는 분명합니다. 유연성을 극대화하려면 원소의 생산자나 소비자용 매개변수에 와일드 카드를 사용합시다. 한편,입력 매개변수가 생상자와 소비자 역할을 동시에 한다면 와일드카드 타입을 써도 좋을 게 없습니다. 타입을 정확히 지정해야 하는 상황으로, 이때는 와일드카드 타입을 쓰지말아야합니다.</br>
 57 | 다음 공식을 외워두면 어떤 와일드 카드 타입을 써야 하는지 도움이 될 것입니다.
 58 | > PECS: producer-extends, consumer-super
 59 | 
 60 | 즉 매개변수화 타입 T가 생성자라면 <? extends T>를 사용하고, 소비자라면 <?super T>를 사용합시다. **클래스 사용자가 와일드카드 타입을 신경 써야 한다면 그 API에 무슨 문제가 있을 가능성이 큽니다.**
 61 | 
 62 | ``` java
 63 | // Item 30에서 사용했던 코드
 64 | public static <E extends Comparable<E>> E max(List<E> c);
 65 | ```
 66 | 이 코드를 와일드카드 타입을 사용해 다듬은 모습입니다.
 67 | ``` java
 68 | // Item 30에서 사용했던 코드
 69 | public static <E extends Comparable<? super E>> E max(List<? extends E> c);
 70 | ```
 71 | 
 72 | 위 코드는 PECS 공식을 두 번 적용했습니다. 입력 매개변수에서는 E 인스턴스를 생산하므로 원래의 List<E>를 List<? extends E>로 수정했습니다. 원래 선언에서는 E가 Comparale<E>를 확장한다고 정의헸는데, 이때 Comparable<E>
 73 | 는 E 인스턴스를 소비합니다.(그리고 선후 관계를 뜻하는 정수를 생산합니다) 그래서 매개변수화 타입 Comparable<E>는 E 한정적 와일드카드 타입 Comparable<? super E>로 대체 했습니다. Comparable은 언제나 소비자이므로, 일반적으로 Comparable, 일반적으로 Comparable<E>보다는 Comparable<? super E>를 사용하는 편이 낫습니다.</br>
 74 | Comparator도 마찬가지입니다. 일반적으로 Comparator<E>보다는 Comparator<? super E>를 사용하는 편이 낫습니다.</br>
 75 | 와일드카드와 관련해 논의해야 할 주제가 더 있습니다. 타입 매개변수와 와일드카드에 공통되는 부분이 있어서, 메서드를 정의할 때 둘 중 어느것을 사용해도 괜찮을 때가 많습니다.
 76 | ``` java
 77 | public static <E> void swap(List<E> list, int i, int j);
 78 | public static swap(List<?> list, int i, int j);
 79 | ```
 80 | public API라면 간단한 두 번째가 낫습니다. 어떤 리스트든 이 메서드에 넘기면 명시한 인덱스의 원소들을 교환해 줄 것입니다. 신경 써야 할 타입 매개변수도 없습니다.</br>
 81 | 기본 규칙은 이렇습니다. **메서드에 선언에 타입 매개변수가 한 번만 나오면 와일드카드로 대체하라.** 이때 비한정적 타입 매개변수라면 비한정적 와일드카드로 바꾸고, 한정적 타입 매개변수라면 한정적 와일드카드로 바꾸면 됩니다.</br>
 82 | 하지만 두 번째 swap 선언에는 문제가 하나 있는데, 다음과 같이 직관적으로 구현한 코드가 컴파일 되지 않는다는 것입니다.
 83 | ``` java
 84 | public static swap(List<?> list, int i, int j) {
 85 |     list.set(i, list.set(j, list.get(i)));
 86 | }
 87 | // 방금 꺼낸 원소를 리스트에 다시 넣을 수 없습니다.
 88 | ```
 89 | 원인 리스트의 타입이 List<?>인데, List<?>에는 null 외에는 어떤 값도 넣을 수 없기 때문입니다.
 90 | ``` java
 91 | public static swap(List<?> list, int i, int j) {
 92 |     swapHelper(list, i, j);
 93 | }
 94 | 
 95 | // 와일드카드 타입을 실제 타입으로 바꿔주는 private 도우미 메서드
 96 | public static <E> void swapHelper(List<E> list, int i, int j) {
 97 |     list.set(i, list.set(j, list.get(i)));
 98 | }
 99 | ```
100 | `swapHelper` 메서드는 리스트가 List<E>임을 알고 있습니다. 즉, 이 리스트에서 꺼낸 값은 항상 E이고, E 타입의 값이라면 이 리스트에 넣어도 안전함을 알고 있습니다. 다소 복잡하지만 덕분에 외부에서는 와일드카드 기반의 멋진 선언을 유지할 수 있습니다. 즉 swap 메서드를 호출 하는 클라이언트는 복잡힌 swapHelper의 존재를 모른 채 그 혜택을 누리는 것입니다.


--------------------------------------------------------------------------------
/chap05/Item32.md:
--------------------------------------------------------------------------------
 1 | # [Item 32] 제네릭과 가변인수를 함께 쓸 때는 신중하라.
 2 | 
 3 | 가변인수와 제네릭은 자바 5에 함께 추가되었는데 이 둘은 서로 어울리지 않습니다.</br>
 4 | 가변인수(varargs)란 메서드에 넘기는 인수의 개수를 클라이언트가 조절할 수 있게 해주는 것입니다. 구현 방식에 허점이 있습나다. 가변인수 메서드를 호출하면 가변인수를 담기 위한 배열이 자동으로 하나 만들어집니다. 그런데 내부로 감춰야 했을 이 배열을 그만  클라이언트에 노출하는 문제가 생겼습니다. 그 결과 verargs 매개변수에 제네릭이나 매개변수화 타입이 포함되면 알기 어려운 컴파일 경고가 발생합니다.
 5 | </br>
 6 | 실체화 불가 타입은 런타임에 컴파일보다 타입 관련 정보를 적게 담고 있습니다. 그리고 거의 모든 제네릭과 매개변수화 타입은 실체화되지 않습니다. 메서드 선언할 때 실체화 불가 타입으로 varargs 매겨변수를 선언하면 컴파일러가 경고를 보냅니다. 가변인수 메서드를 호출할 때도 varags 매개변수가 실체화 불가 타입으로 추론되면, 그 호출에 대해서도 경고를 냅니다.
 7 | </br>
 8 | 매개변수화 타입의 변수가 타입이 다른 다른 객체를 참조하면 힙 오염이 발생합니다. 이렇게 다른 타입 객체를 참조하는 상황에서는 컴파일러가 자동 생성한 형변환이 실패할 수 있으니, 제네릭 타입 시스템이 약속한 타입 안전성의 근간이 흔들려버립니다. 다음 메서드를 예로 생각해봅시다.
 9 | 
10 | ``` java
11 |   static void dangerous(List<String>... stringList) {
12 |     List<Integer> integerList = Collections.singletonList(42);
13 |     Object[] objects = stringList;
14 |     objects[0] = integerList;  // 힙 오염
15 |     String s = stringList[0].get(0); // ClassCaseException
16 |   }
17 | ```
18 | 가변인수와 제네릭을 사용하는 메서드는 대표적으로 Arrys.asList, Collections.addAll등이 있습니다. 자바 7부터는 @SafeVarargs 에너테이션을 사용해서 그 메서드가 타입 안전성을 보장한다는 걸 알려줄 수 있습니다.</br>
19 | 메서드가 이 배열에 아무것도 저장하지 않는다면 괜찮지만 아무것도 저장하지 않고도 타입 안전성을 깨뜨릴 수 있습니다.
20 | 
21 | ``` java
22 | static <T> T[] toArrays(T... args) {
23 |     return args;
24 | }
25 | ```
26 | 이 메서드가 반환하는 타입은 이 메서드에 인수를 넘기는 컴파일타임에 결정되는데, 그 시점에는 컴파일러에게 충분한 정보가 주이지지 않아 타입을 잘못 판단할 수 있습니다. 따라서 varargs 매개변수 배열을 그대로 반환하면 힙 오염을 이 메서드를 호출한 쪽의 콕스 택으로 까지 전이할 수도 있습니다.
27 | 
28 | ```java
29 |   static <T> T[] pickTwo(T a, T b, T c) {
30 |     switch (ThreadLocalRandom.current().nextInt(3)) {
31 |       case 0: return toArrays(a, b);
32 |       case 1: return toArrays(a, c);
33 |       case 2: return toArrays(c, b);
34 |     }
35 |     throw new AssertionError();
36 |   }
37 | ```
38 | toArray 메서드가 돌려준 이 배열이 그대로 pickTwo를 호출한 클라이언트까지 전달되는데 항상 Object[] 타입 배열을 반환하게 됩니다.
39 | ``` java
40 | String[] attributes = pickTwo("좋은", "빠른", "저렴한");
41 | ```
42 | 런타임시 `ClassCastException`을 던집니다. pickTwo에서 Object[]을 반환하는데 String[]으로 변환하려고 해서 예외가 발생합니다.</br>
43 | 배열 내용의 일부 함수를 호출하는(varargs를 받지 않는)일반 메서드에 넘기는 것은 안전합니다.
44 | 
45 | ``` java
46 |   @SafeVarargs
47 |   static <T> List<T> flatten(List<? extends T>... lists) {
48 |     List<T> result = new ArrayList<>();
49 |     for (List<? extends T> list : lists) {
50 |       result.addAll(list);
51 |     }
52 |     return result;
53 |   }
54 | ```
55 | 임의 개수의 리스트를 받아서, 순서대로 그 안의 모든 원소를 하나의 리스트로 옮겨 반환하는 메서드입니다. @SafeVarargs 애너테이션은 안전하지 않은 varargs 메서드에는 절대 작성해서는 안 됩니다. 힙 오염 경고가 뜨면 무조건 검증을 해야합니다. 그리고 재정의할 수 없는 메서드에만 달아야 합니다. 재정의한 메서드도 안전할지는 보장할 수 없기 때문입니다.
56 | 
57 | ``` java
58 |   static <T> List<T> flatten(List<List<? extends T>> lists) {
59 |     List<T> result = new ArrayList<>();
60 |     for (List<? extends T> list : lists) {
61 |       result.addAll(list);
62 |     }
63 |     return result;
64 |   }
65 | ```
66 | 위와 같이  @SafeVarargs 애너테이션을 사용하지 않고 verargs 매개변수를 List 매개변수로 바꿀 수도 있습니다.
67 | ### 정리
68 | - 가변인수와 제네릭은 궁합이 좋지 않습니다.
69 | - 가변인수 기능은 배열을 노출하여 추상화가 완벽하지 못하고, 배열과 제네릭의 타입 규칙이서 서로 다르기 때문입니다.
70 | - 제네릭 verargs 매개변수는 type safe하지 않지만, 허용됩니다.
71 | - verargs 매개변수를 사용하려면 타입이 안전한지 확인하고 @SafeVarargs 애너테이션을 이용합시다.
72 |   


--------------------------------------------------------------------------------
/chap05/Item33.md:
--------------------------------------------------------------------------------
 1 | # [Item 33] 타입 안전 이종 컨테이너를 고려하라
 2 | 타입 안전 이종 컨테이너 패턴이란 키를 매개변수화한 다음, 컨테이너에 값을 넣거나 뺄 때 매개변수화한 키를 함께 제공하는 방식입니다.
 3 | ``` java
 4 | // 타입 안전 이종 컨테이너 패턴 - API
 5 | public class Favorites {
 6 |     public <T> void putFavorite(Class<T> type, T instance);
 7 |     public <T> getFavorite(Class<T> type)
 8 | }
 9 | ```
10 | 다음은 Favorite 클래스를 사용하는 예시입니다.
11 | ``` java
12 | // 타입 안전 이종 컨태이너 패턴 - 클라이언트
13 |     Favorites f = new Favorites();
14 |     
15 |     f.putFavorite(String.class, "JAVA");
16 |     f.putFavorite(Integer.class, 0xcafebabe);
17 |     f.putFavorite(Class.class, Favorite.class);
18 | 
19 |     String favoriteString = f.getFavorite(String.class);
20 |     Integer favoriteInteger = f.getFavorite(Integer.class);
21 |     Class<?> favoriteClass = f.getFavorite(Class.class);
22 | ```
23 | favorite 인스턴스는 type safe합니다. String을 요청했는데 Integer를 반환할 일이 없습니다.
24 | ``` java
25 | // 타입 안전 이종 컨태이너 패턴 - 구현
26 | public class Favorites {
27 |     private Map<Class<?>, Object> favorite = new HashMap<>();
28 |     
29 |     public <T> void putFavorite(Class<T> type, T instance) {
30 |         favorite.put(Objects.requireNonNull(type), instance);
31 |     }
32 | 
33 |     public <T> T getFavorite(Class<T> type) {
34 |         return type.cast(favorites.get(type));
35 |     }
36 | }
37 | 
38 | ```
39 |  Map<Class<?>, Object>에서 비한정적 와일드카드 타입을 사용해서 값을 아무것도 넣을 수 없을 거라고 생각할 수 있지만, 맵이 아니라 키가 와일드카드 타입이라서 값을 넣을 수 있습니다.</br>
40 |  지금 만든 `Favorites` 클래스에 주의점이 두 가지가 있습니다.</br>
41 |  첫 번째는 Class 객체를 raw type으로 넘기면 Favorites 인스턴스의 타입 안전성이 쉽게 깨집니다. Favorites가 타입 불변식이 어기는 일이 없도록 보장하려면 다음과 같이 수정할 수 있습니다.
42 | 
43 |  ``` java
44 | public <T> void putFavorite(Class<T> type, T instance) {
45 |     favorites.put(Objects.requireNonNull(type, type.cast(instance)));
46 | }
47 |  ```
48 |  java.util.Collections에는 `checkedSet`, `checkedList`, `checkedMap` 가 대표적으로 이 방식을 적용한 메서드입니다.
49 |  </br>
50 |  두 번째는 실체화 불가 타입에는 사용할 수 없다는 것입니다. String이나 String[]는 저장할 수 있어도 List<String>은 저장할 수 없습니다. List<String>이나 List<Integer>는 List.class라는 같은 Class 객체를 공유하기 때문입니다.
51 |  ### 정리
52 |  - 컬렉션 API로 대표되는 일반적인 제네릭 형태에서는 한 컨테이너가 다룰 수 있는 타입 매개변수의 수가 고정되어 있습니다.
53 |  - 컨테이너 자체가 아닌 키를 타입 매개변수로 바꾸면 이런 제약이 없는 타입 안전 이종 컨테이너를 만들 수 있습니다.
54 |  - 타입 안전 이종 컨테이너는 Class를 키로 쓰며, 이런 식으로 쓰이는 Class 객체를 타입 토큰이라 합니다.


--------------------------------------------------------------------------------
/chap06/Item34.md:
--------------------------------------------------------------------------------
  1 | # [Item 34] int 상수 대신 열거 타입을 사용하라.
  2 | 
  3 | 열거 타입이란 일정 개수의 상수 값을 정의하고 그 이외 값들은 허용하지 않는 타입입니다. 대표적으로 사계절, 요일, 태양계의 행성 등이 있습니다.
  4 | 
  5 | ### 열거 타입을 지원하기 전 코드
  6 | 
  7 | ``` java
  8 | // 정수 열거 패턴 - 상당히 취약하다.
  9 | public static final int EAST = 0;
 10 | public static final int WEST = 1;
 11 | public static final int SOUTH = 2;
 12 | public static final int NORTH = 3;
 13 | ```
 14 | 이 코드는 타입의 안전성을 보장할 수 없고 표현력도 좋지 않습니다. </br>
 15 | 정수 열거 패턴을 사용한 프로그램은 깨지기가 쉽습니다. 단지 상수를 나열한 것 뿐이라 컴파일하면 그 값이 클라이언트 파일에 그대로 새겨집니다. 따라서 상수의 값이 바뀌면 클라이언트도 수정해줘야 합니다. 
 16 | </br>
 17 | 정수 상수는 그 값을 출력하거나 디버거로 살펴보면 특별한 의미를 나타내는 것이 아니라 단지 숫자로만 보여서 썩 도움이 되지 않습니다. 정수 대신 문자열 상수를 사용하는 방법도 있지만 이 변형 역시 단점이 많습니다. 상수의 의미를 내포할 수 있지만, 문자열 값 그대로 하드코딩 해야하기 때문에 힘듭니다. 이렇게 힘들게 하드코딩한 문자열이 오타가 있어도 컴파일러는 확인할 수 없습니다.</br>
 18 | 
 19 | ### 열거 타입
 20 | ``` java
 21 | // 단순한 열거 타입
 22 | public enum DIRECTION { EAST, WEST, SOUTH, NORTH }
 23 | ```
 24 | 
 25 | 열거 타입 자체는 클래스이며, 상수 하나당 자신의 인스턴스를 하나씩 만들어 **public static final** 필드로 공개합니다. 열거 타입은 컴파일 타임 타입 안전성을 제공합니다. `DIRECTION` 열거 타입을 매개변수로 받는 메서드를 선언 했다면, 건네받은 참조는 null 혹은 DIRECTION의 네 가지 값 중 하나 입니다. 다른 타입의 값을 넘기려 하면 컴파일 오류가 납니다.
 26 | ``` java
 27 | DIRECTION south = "Sounth" // 컴파일 오류 !!!
 28 | ```
 29 | 열거타입에 상수를 추가하거나 순서를 변경해도 다시 컴파일 하지 않아도 됩니다. 공개되는 것이 오직 필드의 이름 뿐이라, 정수 열거 패턴과 달리 상수 값이 클라이언트로 컴파일되어 각인되지 않기 때문입니다. 이처럼 열거 타입은 정수 열거 타입의 단점들을 해소해줍니다. 
 30 | </br>
 31 | 열거 타입에는 메서드나 필드를 추가할 수도 있고 임의의 인터페이스를 구현하게 할 수도 있습니다. `Object`, `Comparable`, `Serializable`을 구현 했으며, 그 직렬화 형태도 웬만큼 변형을 가해도 문제없이 동작하게끔 구현해놨습니다.
 32 | 
 33 | ### 메서드와 필드를 추가한 enum 예제
 34 | ``` java
 35 | public enum Planet {
 36 |   MERCURY(3.302e+23, 2.439e6),
 37 |   VENUS(4.869e+24, 6.052e6),
 38 |   EARTH(5.975e+24, 6.378e6),
 39 |   MARS(6.419e+23, 3.393e6),
 40 |   JUPITER(1.899e+27, 7.149e7),
 41 |   SATURN(5.685e+26, 6.027e7),
 42 |   URANUS(8.683e+25, 2.556e7),
 43 |   NEPTUNE(1.024e+26, 2.477e7);
 44 |   
 45 |   private final double mass; // 질량(단위: 킬로그램)
 46 |   private final double radius; // 반지름(단위: 미터)
 47 |   private final double surfaceGravity; // 표면 중력(단위: m / s^2)
 48 |   
 49 |   // 중력 상수(단위: m^3 / kg s^2)
 50 |   private static final double G = 6.67300E-11;
 51 | 
 52 |   // Constructor
 53 |   Planet(double mass, double radius) {
 54 |     this.mass = mass;
 55 |     this.radius = radius;
 56 |     surfaceGravity = G * mass / (radius * radius);
 57 |   }
 58 | 
 59 |   public double mass() {
 60 |     return mass;
 61 |   }
 62 | 
 63 |   public double radius() {
 64 |     return radius;
 65 |   }
 66 | 
 67 |   public double surfaceGravity() {
 68 |     return surfaceGravity;
 69 |   }
 70 | 
 71 |   public double surfaceWeight(double mass) {
 72 |     return mass * surfaceGravity;  // F = ma
 73 |   }
 74 | }
 75 | ```
 76 | 열거 타입을 선언한 클래스 혹은 그 패키지에서만 유용한 기능은 private이나 package-private 메서드로 구현하는 게 좋습니다. 일반 클래스와 마찬가지로, 그 기능을 클라이언트에 노출해야 할 합당한 이유가 없다면 private 혹은 package-private으로 선언하라(Item 15)랑 같습니다.
 77 | </br>
 78 | 
 79 | ### 추천하지 않는 코드
 80 | 
 81 | ``` java
 82 | public enum Operation {
 83 | 
 84 |   PLUS, MINUS, TIMES, DIVIDE;
 85 | 
 86 |   // 상수가 뜻하는 연산을 수행한다.
 87 |   public double apply(double x, double y) {
 88 |     switch (this) {
 89 |       case PLUS: return x + y;
 90 |       case MINUS: return x - y;
 91 |       case TIMES: return x * y;
 92 |       case DIVIDE: return x / y;
 93 |     }
 94 |     throw new AssertionError("알 수 없는 연산: " + this);
 95 |   }
 96 | }
 97 | ```
 98 | 동작은 하지만 맹점이 있습니다. 예컨대 새로운 상수를 추가하면 해당 case 문도 추가해야 합니다. 열거 타입에 apply를 이용하여 코드를 보완할 수 있습니다. 
 99 | ### 상수별 메서드 구현을 활용한 열거 타입
100 | ``` java
101 | // 상수별 메서드 구현
102 | public enum Operation {
103 | 
104 |   PLUS {
105 |     public double apply(double x, double y) {
106 |       return x + y;
107 |     }
108 |   }, MINUS {
109 |     public double apply(double x, double y) {
110 |       return x - y;
111 |     }
112 |   }, TIMES {
113 |     public double apply(double x, double y) {
114 |       return x * y;
115 |     }
116 |   }, DIVIDE {
117 |     public double apply(double x, double y) {
118 |       return x / y;
119 |     }
120 |   };
121 | 
122 |   public abstract double apply(double x, double y);
123 | }
124 | ```
125 | 보시다시피 apply 메서드가 상수 선언 바로 옆에 붙어 있으니 새로운 상수를 추가할 때 apply도 재정의해야 한다는 사실을 깜빡하기는 어려울 것입니다. 그 뿐만 아니라 apply 메서드가 추상 메서드이므로 재정의 하지 않았다면 컴파일 오류로 알려줍니다. 상수별 메서드 구현을 상수별 데이터와 결합할 수도 있습니다. 
126 | 예컨대 다음은 Operation의 toString을 재정의해 해당 연산을 뜻하는 기호를 반환하도록 하는 예제 코드입니다.
127 | 
128 | ``` java
129 | public enum Operation {
130 |   PLUS("+") {
131 |     public double apply(double x, double y) {
132 |       return x + y;
133 |     }
134 |   },
135 |   MINUS("-") {
136 |     public double apply(double x, double y) {
137 |       return x - y;
138 |     }
139 |   },
140 |   TIMES("*") {
141 |     public double apply(double x, double y) {
142 |       return x * y;
143 |     }
144 |   },
145 |   DIVIDE("/") {
146 |     public double apply(double x, double y) {
147 |       return x / y;
148 |     }
149 |   };
150 |   private final String symbol;
151 | 
152 |   Operation(String symbol) {
153 |     this.symbol = symbol;
154 |   }
155 | 
156 |   @Override
157 |   public String toString() {
158 |     return symbol;
159 |   }
160 | 
161 |   public abstract double apply(double x, double y);
162 | }
163 | ```
164 | 
165 | 열거 타입에는 상수 이름을 입력받아 그 이름에 해당하는 상수를 반환하는 valueOf(String) 메서드가 자동 생성됩니다. 
166 | </br>
167 | </br>
168 | 상수별 메서드 구현에는 열거 타입 상수끼리 코드를 공유하기 어렵다는 단점이 있습니다. 다음은 급명세서에서 쓸 요일을 표현하는 로직을 포함한 열거 타입 예제입니다.
169 | 
170 | ``` java
171 | // 위험한 코드
172 | 
173 | enum PayrollDay {
174 |   MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY,
175 |   SATURDAY(PayType.WEEKEND), SUNDAY(PayType.WEEKEND);
176 | 
177 |   private final PayType payType;
178 | 
179 |   PayrollDay(PayType payType) {
180 |     this.payType = payType;
181 |   }
182 | 
183 |   PayrollDay() {
184 |     this(PayType.WEEKDAY);
185 |   }  // Default
186 | 
187 |   int pay(int minutesWorked, int payRate) {
188 |     return payType.pay(minutesWorked, payRate);
189 |   }
190 | 
191 |   // The strategy enum type
192 |   private enum PayType {
193 |     WEEKDAY {
194 |       int overtimePay(int minsWorked, int payRate) {
195 |         return minsWorked <= MINS_PER_SHIFT ? 0 :
196 |             (minsWorked - MINS_PER_SHIFT) * payRate / 2;
197 |       }
198 |     },
199 |     WEEKEND {
200 |       int overtimePay(int minsWorked, int payRate) {
201 |         return minsWorked * payRate / 2;
202 |       }
203 |     };
204 | 
205 |     abstract int overtimePay(int mins, int payRate);
206 | 
207 |     private static final int MINS_PER_SHIFT = 8 * 60;
208 | 
209 |     int pay(int minsWorked, int payRate) {
210 |       int basePay = minsWorked * payRate;
211 |       return basePay + overtimePay(minsWorked, payRate);
212 |     }
213 |   }
214 | }
215 | ```
216 | 하지만 기존 열거 타입에 상수별 동작을 혼합해 넣을 때는 switch 문이 좋은 선택이 될 수도 있습니다.
217 | 
218 | ``` java
219 | // switch문을 이용해 원래 열거 타입에 없는 기능을 수행
220 | public static Operation inverse(Operation op) {
221 |   switch(op) {
222 |     case PLUS:   return Operation.MINUS;
223 |     case MINUS:  return Operation.PLUS;
224 |     case TIMES:  return Operation.DIVIDE;
225 |     case DIVIDE: return Operation.TIMES;
226 |     default: thrownewAssertionError("알 수 없는 연산: "+op); 
227 |   }
228 | }
229 | ```
230 | 추가하려는 메서드가 의미상 열거 타입에 속하지 않는다면 이 방식을 적용하는 게 좋습니다. 열거 타입은 메모리에 올라가는 공간과 초기화하는 시간이 좀 들긴 하지만 크게 체감될 정도는 아닙니다.


--------------------------------------------------------------------------------
/chap06/Item35.md:
--------------------------------------------------------------------------------
 1 | # [Item 35] ordinal 메서드 대신 인스턴스 필드를 사용하라
 2 | 
 3 | 대부분 열거 타입 상수는 자연스럽게 하나의 정숫값에 대응됩니다. 모든 엵 ㅓ타입은 해당 상수가 그 열거 타입에서 몇 번째 위치인지를 반환하는 ordinal 이라는 메서드를 제공합니다.
 4 | 
 5 | ``` java
 6 | // ordinal을 잘못 사용한 예
 7 | public enum FRUITS {
 8 | 
 9 |   APPLE, BANANA, ORANGE;
10 | 
11 |   public int numberOfFruits() {
12 |     return ordinal() + 1;
13 |   }
14 | }
15 | 
16 | ```
17 | 상수 선언 순서를 바꾸는 순간 numberOfFruits는 오작동하며 이미 사용중인 정수와 값이 같은 상수는 추가할 수 없고 중간에 값을 비울 수도 없습니다.</br>
18 | 해결책은 매우 간단합니다. ordinal 메서드를 이용하지 않고 인스턴스 필드에 저장하면 됩니다.
19 | ``` java
20 | public enum FRUITS {
21 |   APPLE(1), BANANA(2), ORANGE(3);
22 |   
23 |   private final int numberOfFruits;
24 | 
25 |   FRUITS(int size) {
26 |     this.numberOfFruits = size; 
27 |   }
28 | 
29 |   public int getNumberOfFruits() {
30 |     return numberOfFruits;
31 |   }
32 | }
33 | ```
34 | Enum의 API 문서에는 ordinal에 대해서 "대부분 프로그래머는 이 메서드를 쓸 일이 없습니다. 이 메서드는 EnumSet과 EnumMap 같이 열거 타입 기반의 범용 자료구조에 쓸 목적으로 설계되었습니다."


--------------------------------------------------------------------------------
/chap06/Item36.md:
--------------------------------------------------------------------------------
 1 | # [Item 36] 비트 필드 대신 EnumSet을 사용하라.
 2 | 
 3 | 열거한 값들이 집합으로 사용될 경우, 예전에는 상수에 서로 다른 2의 거듭제곱 값을 할당한 정수 열거 패턴을 사용해왔습니다.
 4 | 
 5 | ``` java
 6 | // 비트 필드 열거 상수 - 구닥다리 기법
 7 |    public class Text {
 8 |        public static final int STYLE_BOLD = 1 << 0; // 1
 9 |        public static final int STYLE_ITALIC = 1 << 1; // 2
10 |        public static final int STYLE_UNDERLINE = 1 << 2; // 4
11 |        public static final int STYLE_STRIKETHROUGH = 1 << 3;  // 8
12 | 
13 |        // 매개변수 styles는 0개 이상의 STYLE_ 상수를 비트별 OR한 값입니다.
14 |        public void applyStyles(int styles) { ... }
15 |    }
16 | ```
17 | 다음과 같은 식으로 비트별 OR를 사용해 여러 상수를 하나의 집합으로 모을 수 있으며, 이렇게 만들어진 집합을 비트 필드라고 합니다.
18 | ``` java
19 | text.applyStyles(Text.STYLE_BOLD | Text.STYLE_ITALIC);
20 | ```
21 | 비트 필드를 사용하면 비트별 연산을 사용해 집합 연산을 효율적으로 사용할 수 있지만, 정수 열거 상수와 같은 단점을 지니고 있으며 추가로 다음과 같은 단점들이 있습니다.
22 | </br>
23 | 1. 비트 필드 값이 그대로 출력되면 정수 열거 상수를 출력할 때보다 해석하기가 훨씬 어렵습니다.
24 | 2. 비트 필드 하나에 녹아 있는 모든 원소를 순회하기도 까다롭습니다.
25 | 3. 최대 몇 비트가 필요한지를 API 작성 시 미리 예측하여 적절한 타입을 선택해야 합니다. API를 수정하지 않고는 비트 수를 더 늘릴 수 없기 때문입니다.
26 | </br>
27 | `EnumSet`을 이용하면 이러한 단점을 보완하여 사용할 수 있습니다. EnumSet의 내부는 비트 벡터로 구현되어있고, 원소가 총 64개 이하라면 EnumSet 전체를 long 변수 하나로 표현하여 비트 필드에 비견되는 성능을 보여줍니다.
28 | 
29 | ``` java
30 | public class Text {
31 |     public enum Style { BOLD, ITALIC, UNDERLINE, STRIKETHROUGH }
32 | 
33 |        // 어떤 Set을 넘겨도 됩지만 EnumSet이 가장 좋습니다.
34 |        public void applyStyles(Set<Style> styles) { ... }
35 | }
36 | ```
37 | EnumSet을 이용한 클라이언트 코드
38 | ``` java
39 | text.applyStyles(EnumSet.of(Style.BOLD, Style.ITALIC));
40 | ```
41 | ### 정리
42 | - 열거할 수 있는 타입을 모아 집합 형태로 사용한다고 해도 비트 필드를 사용할 이유는 없습니다.
43 | - 비트 필드의 단점이 보완되는 EnumSet을 활용합시다.


--------------------------------------------------------------------------------
/chap06/Item37.md:
--------------------------------------------------------------------------------
 1 | # [Item 37] ordinal 인덱싱 대신 EnumMap을 사용하라.
 2 | 
 3 | ``` java
 4 | public class Plant {
 5 |   enum LifeCycle { ANNUAL, PERENNIAL, BIENNIAL }
 6 | 
 7 |   final String name;
 8 |   final LifeCycle lifeCycle;
 9 | 
10 |   Plant(String name, LifeCycle lifeCycle) {
11 |     this.name = name;
12 |     this.lifeCycle = lifeCycle;
13 |   }
14 | 
15 |   @Override
16 |   public String toString() {
17 |     return name;
18 |   }
19 | }
20 | ```
21 | 식물을 간단히 나타낸 코드입니다. 이들을 생애주기 별로 묶어봅시다.생애주기별로 총 3개의 집합을 만들고 정원을 한 바퀴 돌며 식물을 해당 집합에 집어넣습니다.
22 | ``` java
23 |    Map<Plant.LifeCycle, Set<Plant>> plantsByLifeCycle =
24 |        new EnumMap<>(Plant.LifeCycle.class);
25 |    for (Plant.LifeCycle lc : Plant.LifeCycle.values())
26 |        plantsByLifeCycle.put(lc, new HashSet<>());
27 |    for (Plant p : garden)
28 |        plantsByLifeCycle.get(p.lifeCycle).add(p);
29 |    System.out.println(plantsByLifeCycle);
30 | ```
31 | `EnumMap`은 열거타입 키를 사용하도록 설계한 아주 빠른 Map 구현체 입니다. EnumMap의 생성자가 받는 키 타입의 Class 객체는 한정적 타입 토큰으로 런타임 제네릭 타입 정보를 제공합니다. </br>
32 | 스트림을 사용해 맵을 관리하면 코드를 더 줄일 수 있습니다.
33 | ``` java
34 | System.out.println(Arrays.stream(garden)
35 |            .collect(groupingBy(p -> p.lifeCycle)));
36 | ```
37 | 이 코드는 EnumMap이 아닌 고유한 맵 구현체를 사용했기 때문에 EnumMap을 써서 얻은 공간과 성능 이점이 사라진다는 단점이 있습니다. 좀 더 자세히 살펴보면
38 |  매개변수 3개짜리 Collectors.groupingBy 메서드는 mapFactory 매개변수에 원하는 맵 구현체를 명시해 호출할 수 있습니다.
39 | ``` java 
40 | // EnumMap을 이용해 데이터 열거 타입과 매핑
41 |  System.out.println(Arrays.stream(garden)
42 |         .collect(groupingBy(p -> p.lifeCycle,
43 |         () -> new EnumMap<>(LifeCycle.class), toSet())));
44 | ```
45 | 맵을 빈번히 사용하는 프로그램에는 도움이 될 것입니다.</br>
46 | 스트림을 사용하면 EnumMap만 사용했을 때와는 다른 점이 있습니다. EnumMap 버전은 언제나 식물의 생애주기당 하나씩의 중첩 맵을 만들지만, 스트림 버전은 해당 생애주기에 속하는 식물이 있을 떄만 만듭니다.
47 | 


--------------------------------------------------------------------------------
/chap06/Item38.md:
--------------------------------------------------------------------------------
 1 | # [Item 38] 확장할 수 있는 열거 타입이 필요하면 인터페이스를 사용하라.
 2 | 
 3 | 열거 타입은 확장할 수 없게 설계 되었습니다. 확장한 타입의 원소는 기반 타입의 원소로 취급하지만 그 반대는 성립하지 않는다면 어폐가 있고 기반 타입과 확장된 타입들의 원소를 모두를 순회할 방법도 마땅치 않으며 확장성을 높이려면 고려할 요소가 늘어나 설계와 구현이 더 복잡해지기 때문입니다.
 4 | </br>
 5 | 그러나 연산 코드는 확장할 수 있는 열거 타입과 어울립니다. API가 제공하는 기본 연산 외에 사용자가 확장 연산을 추가할 수 있도록 열어줘야 할 때가 있습니다. 
 6 | 
 7 | ``` java
 8 | package com.example.jpatest.t;
 9 | 
10 | public interface Operation {
11 | 
12 |   double apply(double x, double y);
13 | }
14 | 
15 | public enum BasicOperation implements Operation {
16 |   PLUS("+") {
17 |     public double apply(double x, double y) {
18 |       return x + y;
19 |     }
20 |   },
21 |   MINUS("-") {
22 |     public double apply(double x, double y) {
23 |       return x - y;
24 |     }
25 |   },
26 |   TIMES("*") {
27 |     public double apply(double x, double y) {
28 |       return x * y;
29 |     }
30 |   },
31 |   DIVIDE("/") {
32 |     public double apply(double x, double y) {
33 |       return x / y;
34 |     }
35 |   };
36 | 
37 |   private final String symbol;
38 | 
39 |   BasicOperation(String symbol) {
40 |     this.symbol = symbol;
41 |   }
42 | 
43 |   @Override
44 |   public String toString() {
45 |     return symbol;
46 |   }
47 | }
48 | ```
49 | `Operation`인터페이스를 구현하여 구현체가 다른 열거 타입을 이용할 수 있습니다.
50 | 
51 | ``` java
52 | // 구현체를 메서드에 명시해서 사용하는 방식
53 | public static void main(String[] args) {
54 |     double x = Double.parseDouble(args[0]); 
55 |     double y = Double.parseDouble(args[1]); 
56 |     test(ExtendedOperation.class, x, y);
57 | }
58 | private static <T extends Enum<T> & Operation> void test( Class<T> opEnumType, double x, double y) {
59 |     for (Operation op : opEnumType.getEnumConstants())
60 |         System.out.printf("%f %s %f = %f%n", x, op, y, op.apply(x, y));
61 | }
62 | ```
63 | 
64 | 여기서 class 리터럴은 한정적 타입토큰 역할을 합니다.
65 | 
66 | ``` java
67 | // 두 번째 방법
68 | public static void main(String[] args) {
69 |     double x = Double.parseDouble(args[0]);
70 |     double y = Double.parseDouble(args[1]); 
71 |     test(Arrays.asList(ExtendedOperation.values()), x, y);
72 | }
73 | private static void test(Collection<? extends Operation> opSet, double x, double y) {
74 |     for (Operation op : opSet)
75 |         System.out.printf("%f %s %f = %f%n",x, op, y, op.apply(x, y));
76 | }
77 | ```
78 | 여러 구현 타입의 연산을 조합해 호출할 수 있게 되므로 더 유연해졌습니다 하지만 특정 연산에서는 EnumMap과 EnumSet을 사용하지 못합니다.</br>
79 | 인터페이스를 활용하는 방법에는 사소한 문제가 있습니다. 열거 타입끼리 구현을 상속할 수 없다는 점입니다. 아무 상태에도 의존하지 않는 경우에는 디폴트 구현을 이용해 인터페이스에 추가하는 방방이 있습니다. 하지만 모든 구현체에 공유해야 하므로 공유하는 기능이 많다면 그 부분을 별도의 도우미 클래스나 정적 도우미 메서드로 분리하는 방식으로 코드 중복을 없앨 수 있습니다.
80 | 
81 | 한 줄 요약: 열거 타입 자체는 확장할 수 없지만 인터페이스와 인터페이스를 구현하는 열거 타입을 함께 사용하면 같은 효과를 낼 수 있습니다.
82 | 


--------------------------------------------------------------------------------
/chap06/Item39.md:
--------------------------------------------------------------------------------
  1 | # [Item 39] 명명 패턴보다 애너테이션을 사용하라.
  2 | 
  3 | 명명 패턴의 대표적인 예로 `JUnit 3`까지는 테스트 메서드 이름을 test로 시작하지 않으면 이 메서드를 그냥 지나쳤서 테스트를 통과했다고 오해하는 경우도 있었습니다.</br>
  4 | `JUnit 4`부터는 이러한 문제점을 해결하기 위해 **애너테이션**을 전면 도입했습니다. 이번 예제에서는 자동으로 수행되는 간단한 테스트용 애너테이션으로, 예외가 발생하면 해당 테스트를 실패로 처리합니다.
  5 | 
  6 | ``` java
  7 | /**
  8 |  * 테스트 메서드임을 선언하는 애너테이션
  9 |  * 매개변수 없는 정적 메서드 전용
 10 |  */
 11 | @Retention(RetentionPolicy.RUNTIME)
 12 | @Target(ElementType.METHOD)
 13 | public @interface Test {
 14 | }
 15 | ```
 16 | 
 17 | `@Retention`, `@Target`과 같이 애너테이션 선언에 다는 애너테이션을 **메타애너테이션**이라 합니다. 쉽게 설명하면 메타 애너테이션은 애너테이션을 위한 애너테이션이라고 생각하시면 됩니다.</br>
 18 | `@Retention`은 애너테이션이 유지되는 기간이며 @Retention(RetentionPolicy.RUNTIME)은 런타임까지 존재한다는 뜻입니다.</br>
 19 | `@Target`은 적용 대상을 지정할 때 사용하며 @Target(ElementType.METHOD)은 메서드 선언에만 사용할 수 있다는 뜻입니다. 위 코드에서 "매개변수 없는 정적 메서드 전용"라고 주석을 작성했는데, 적절한 애너테이션 처리기를 직접 구현하지 않으면 컴파일 오류 없이 잘 작동합니다.
 20 |  </br>
 21 | 
 22 |  ``` java
 23 |  public class Sample {
 24 | 
 25 |   @Test
 26 |   public static void m1() {} // 성공해야 한다
 27 | 
 28 |   public static void m2() {} 
 29 | 
 30 |   @Test
 31 |   public static void m3() { // 실패해ㅑ 한다
 32 |     throw new RuntimeException("Boom");
 33 |   }
 34 | 
 35 |   public static void m4() {}
 36 | 
 37 |   @Test
 38 |   public void m5() {} // 잘못 사용: 정적 메서드가 아님
 39 | 
 40 |   @Test
 41 |   public static void m7() { // 실패해야 한다
 42 |     throw new RuntimeException("Crash");
 43 |   }
 44 | 
 45 |   public static void m8() {}
 46 | }
 47 |  ```
 48 |  @Test 애너테이션은 Sample클래스에 직접적인 영향을 주지 않습니다. 그저 이 애너테이션에 관심 있는 프로그램에게 추가 정보를 제공할 뿐입니다.
 49 | 
 50 |  ``` java
 51 |  // 마커 애너테이션을 처리하는 코드
 52 |  public class RunTest {
 53 | 
 54 |   public static void main(String[] args) throws Exception {
 55 |     int tests = 0;
 56 |     int passed = 0;
 57 |     Class<?> testClass = Class.forName(args[0]);
 58 | 
 59 |     for (Method m : testClass.getDeclaredMethods()) {
 60 |       if (m.isAnnotationPresent(Test.class)) {
 61 |         tests++;
 62 |         try {
 63 |           m.invoke(null);
 64 |           passed++;
 65 |         } catch (InvocationTargetException wrappedExc) {
 66 |           Throwable exc = wrappedExc.getCause();
 67 |           System.out.println(m + " failed: " + exc);
 68 |         } catch (Exception exc) {
 69 |           System.out.println("Invalid @Test: " + m);
 70 |         }
 71 |       }
 72 |     }
 73 |     System.out.printf("Passed: %d, Failed: %d%n", passed, tests - passed);
 74 |   }
 75 | }
 76 |  ```
 77 | @Test 애너테이션이 달린 메서드를 차례로 호출합니다. `isAnnotationPresent`메서드가 실행할 메서드를 찾아줍니다. `InvocationTargetException`외의 예외가 발생한다면 @Test 애너테이션을 잘못 사용했다는 뜻입니다.인스턴스 메서드, 매개변수가 있는 메서드, 호출할 수 없는 메서드 등에 사용했다는 뜻입니다. </br></br>
 78 | 이번에는 특정 예외를 던져야만 성공하는 테스트를 지원하도록 해봅시다.
 79 | ``` java
 80 | /**
 81 |  * 명시한 예외를 던져야면 성공하는 테스트 메서드용 에너테이
 82 |  */
 83 | @Retention(RetentionPolicy.RUNTIME)
 84 | @Target(ElementType.METHOD)
 85 | public @interface ExceptionTest {
 86 |   Class<? extends Throwable> value();
 87 | }
 88 | ```
 89 | `Throwable`을 확장한 클래스의 Class 객체라는 뜻이며, 따라서 모든 예외,오류 타입을 수용합니다. 이는 한정적 타입 토큰을 활용한 사례입니다. 다음은 이 애너테이션을 실제 활용한 모습입니다.
 90 | 
 91 | ``` java
 92 | public class Sample2 {
 93 | 
 94 |   @ExceptionTest(ArithmeticException.class)
 95 |   public static void m1() {
 96 |     int i = 0 / 0;
 97 |   }
 98 | 
 99 |   @ExceptionTest(ArithmeticException.class)
100 |   public static void m2() {
101 |     int[] a = new int[0]; // 실패해야 한다. (다른 예외 발생)
102 |     int i = a[1];
103 |   }
104 | 
105 |   @ExceptionTest(ArithmeticException.class)
106 |   public static void m3() { } // 실패해야 한다. (예외 발생 x)
107 | }
108 | ```
109 | 
110 | 이제 이 애너테이션을 다룰 수 있는 코드를 작성해봅시다. (앞서 작성한 코드의 일부분을 수정했습니다)
111 | ``` java
112 |       if (m.isAnnotationPresent(ExceptionTest.class)) {
113 |         tests++;
114 |         try {
115 |           m.invoke(null);
116 |           System.out.printf("테스트 %s 실패: 예외를 던지지 않음%n", m);
117 |         } catch (InvocationTargetException wrappedEx) {
118 |           Throwable exc = wrappedEx.getCause();
119 |           Class<? extends Throwable> excType =
120 |               m.getAnnotation(ExceptionTest.class).value();
121 |           if (excType.isInstance(exc)) {
122 |             passed++;
123 |           } else {
124 |             System.out.printf(
125 |                 "테스트 %s 실패: 기대한 예외 %s, 발생한 예외 %s%n",
126 |                 m, excType.getName(), exc);
127 |           }
128 |         } catch (Exception exc) {
129 |           System.out.println("잘못 사용한 @ExceptionTest: " + m);
130 |         }
131 |       }
132 | 
133 | ```
134 | 문제 없이 컴파일이 되면애너테이션 매개변수가 가리키는 예외가 올바르단 뜻입니다. 예외를 하나가 아닌 여러개를 명시하고 그 중 하나가 발생하면 성공하게 만들 수도 있습니다.
135 | </br>
136 | 
137 | ``` java
138 | @Retention(RetentionPolicy.RUNTIME)
139 | @Target(ElementType.METHOD)
140 | public @interface ExceptionTest {
141 |   Class<? extends Throwable>[] value();
142 | }
143 | ```
144 | 
145 | ``` java
146 | @ExceptionTest({ IndexOutOfBoundsException.class,
147 |                 NullPointerException.class }) 
148 | public static void doSomething() {
149 |     ...
150 | }
151 | ``` 
152 | 다음은 클라이언트 코드를 수정한 모습입니다.
153 | ``` java
154 |       if (m.isAnnotationPresent(ExceptionTest.class)) {
155 |         tests++;
156 |         try {
157 |           m.invoke(null);
158 |           System.out.printf("테스트 %s 실패: 예외를 던지지 않음%n", m);
159 |         } catch (Throwable wrappedExc) {
160 |           Throwable exc = wrappedExc.getCause();
161 |           int oldPassed = passed;
162 |           Class<? extends Throwable>[] excTypes =
163 |               m.getAnnotation(ExceptionTest.class).value();
164 |           for (Class<? extends Throwable> excType : excTypes) {
165 |             if (excType.isInstance(exc)) {
166 |               passed++;
167 |               break;
168 |             }
169 |           }
170 |           if (passed == oldPassed) {
171 |             System.out.printf("테스트 %s 실패: %s %n", m, exc);
172 |           }
173 |         }
174 |       }
175 | ```
176 | 자바 8에서는 여러 개의 값을 받는 애너테이션을 다른 방식으로 만들 수 있습니다. 배열 매개변수를 사용하는 대신 애너테이션에 `@Repeatabl` 메타 애너테이션을 다는 방식입니다.</br>
177 | @Repeatabl를 사용 할 때 주의사항이 있습니다. @Repeatable을 단 애너테이션을 반환하는 '컨테이너 애너테이션'을 하나 더 정의하고, @Repeatable에 컨테이너 애너테이션에 class객체를 매개변수로 전달해야 합니다. 또 컨테이션 애너테이션은 내부 애너테이션 타입의 배열을 반환하는 value 메서드를 정의해아 합니다. 
178 | 
179 | ``` java
180 | @Retention(RetentionPolicy.RUNTIME)
181 | @Target(ElementType.METHOD)
182 | @Repeatable(ExceptionTestContainer.class)
183 | public @interface ExceptionTest {
184 |   Class<? extends Throwable> value();
185 | }
186 | 
187 | // 컨테이너 애너테이션
188 | @Retention(RetentionPolicy.RUNTIME)
189 | @Target(ElementType.METHOD)
190 | public @interface ExceptionTestContainer {
191 |   ExceptionTest[] value();
192 | }
193 | 
194 | @ExceptionTest(IndexOutOfBoundsException.class)
195 | @ExceptionTest(NullPointerException.class) 
196 | public static void doSomething() {
197 |     ...
198 | }
199 | ```
200 | 다음은 RunTests 프로그램이 @ExceptionTest의 반복 가능 버전을 사용하도록 수정한 코드입니다.
201 | ``` java
202 |       if (m.isAnnotationPresent(ExceptionTest.class)
203 |           || m.isAnnotationPresent(ExceptionTestContainer.class)) {
204 |         tests++;
205 |         try {
206 |           m.invoke(null);
207 |           System.out.printf("Test %s failed: no exception%n", m);
208 |         } catch (Throwable wrappedExc) {
209 |           Throwable exc = wrappedExc.getCause();
210 |           int oldPassed = passed;
211 |           ExceptionTest[] excTests =
212 |               m.getAnnotationsByType(ExceptionTest.class);
213 |           for (ExceptionTest excTest : excTests) {
214 |             if (excTest.value().isInstance(exc)) {
215 |               passed++;
216 |               break;
217 |             }
218 |           }
219 |           if (passed == oldPassed) {
220 |             System.out.printf("Test %s failed: %s %n", m, exc);
221 |           }
222 |         }
223 | 
224 | ```
225 | 이번 Test예제에서는 애노테이션으로 할 수 있는 일들 중 극히 일부 입니다. 하지만 일반적으로 프로그래머가 애너테이션을 직접 정의할 일은 드뭅니다. 하지만 자바 프로그래머라면 자바가 제공하는 애너테이션 타입들은 사용할 줄 알아야합니다.


--------------------------------------------------------------------------------
/chap06/Item40.md:
--------------------------------------------------------------------------------
 1 | # [Item 40] @Override 애너테이션을 일관되게 사용하여라.
 2 | 
 3 | `@Override`애너테이션은 상위 타입 메서드를 재정의 했다는 뜻으로 메서드 선언에 달 수 있습니다.
 4 | 
 5 | ``` java
 6 | // 버그를 찾아보자
 7 |  public class Bigram {
 8 | 
 9 |   private final char first;
10 |   private final char second;
11 | 
12 |   public Bigram(char first, char second) {
13 |     this.first = first;
14 |     this.second = second;
15 |   }
16 | 
17 |   public boolean equals(Bigram b) {
18 |     return b.first == first && b.second == second;
19 |   }
20 | 
21 |   public int hashCode() {
22 |     return 31 * first + second;
23 |   }
24 | 
25 |   public static void main(String[] args) {
26 |     Set<Bigram> s = new HashSet<>();
27 |     for (int i = 0; i < 10; i++) {
28 |       for (char ch = 'a'; ch <= 'z'; ch++) {
29 |         s.add(new Bigram(ch, ch));
30 |       }
31 |     }
32 |     System.out.println(s.size());
33 |   }
34 | }
35 | ```
36 | `Set`은 중복이 허용되지 않아서 26을 출력할 거 같지만 실제로 260이 출력됐습니다. 어디가 잘못 됐을까요?
37 | </br>
38 | 정답은 `equals`를 '재정의' 한 게 아니라 '다중정의'를 해서 그렇습니다. Object의 equals를 재정의 하려면 매개변수 타입을 `Object`로 해야하는데 다른 타입을 지정해서 새로운 equals를 만들게 된 것입니다. 따라서 Hash를 사용할 때 원하는 데로 결과값을 도출할 수 없었던 것입니다.
39 | 
40 | ``` java
41 |   @Override
42 |   public boolean equals(Bigram b) {
43 |     return b.first == first && b.second == second;
44 |   }
45 | ```
46 | 이런식으로 애너테이션을 달면 컴파일 오류가 발생하므로 쉽게 오류를 수정할 수 있습니다. 그러니 상위 클래스의 메서드를 재정의할 때는 @Override 애너테이션을 달도록 합시다. 예외적으로 구체 클래스에서 상위 클래스의 추상 메서드를 재정의 할 때는 굳이 사용하지 않아도 되긴 합니다. 구체 클래스인데 아직 구현하지 않은 추상 메서드가 남아 있다면 컴파일러가 알려주기 떄문입니다. 그래도 일관성과 가시성을 위해 달아주는 게 좋습니다.
47 | 
48 | 
49 | 


--------------------------------------------------------------------------------
/chap06/Item41.md:
--------------------------------------------------------------------------------
 1 | # [Item 41] 정의하려는 것이 타입이라면 마커 인터페이스를 사용하라.
 2 | 
 3 | **마커 인터페이스**란 메서드 선언을 포함하지 않고, 단지 구현하는 클래스의 특정 속성을 표시해주는 것입니다. 대표적으로 `Serializable`인터페이스가 있습니다.</br>
 4 | 마커 애너테이션이 등장하면서 마커 인터페이스가 구식이 되었다는 얘기가 있는데, 이는 사실이 아닙니다. 마커 인터페이스는 마커 애너테이션 보다 좋은 점도 있습니다.</br>
 5 | 첫 째로 마커 인터페이스는 이를 구현한 클래스의 인스턴스들을 구분하는 타입을 쓸 수 있지만, 마커 애너테이션은 그렇지 않습니다. 마커 인터페이스는 타입이고 마커 애너테이션을 사용하면 런타임에야 발견할 수 있습니다.</br>
 6 | 자바의 직렬화는 `Serializable` 마커 인터페이스를 보고 그 대상이 직렬화를 할 수 있는 타입인지 확인합니다. 예를들어 ObjectOutputStream.writeObject 메서드는 당연히 인수로 받은 객체가 Serializable를 구현 했을 거라고 가정합니다. 하지만 이 메서드는 Object 객체를 받도록 설계되어서 직렬화할 수 없는 객체를 넘겨도 런타임에야 확인할 수 있습니다. 이는 마커 인터페이스의 이점을 살리지 못한 것입니다.
 7 | 
 8 | </br></br>
 9 | 두 번째는 적용 대상을 더 **정밀**하게 지정할 수 있다는 것입니다. 특정 인터페이스를 구현한 클래스에만 적용하고 싶으먼 그 클래스에 마커 인터페이스를 구현하기만 하면 됩니다.</br>
10 | 반대로 마커 애너테이션이 마커 인터페이스보다 좋은 점은 거대한 애너테이션 시스템의 지원을 받을 수 있다는 점입니다. 둘 중 어느것을 사용해야될지 모르는 경우 확실한 건 클래스와 인터페이스 외의 프로그램요소(모듈, 패키지, 필드 등)에 마킹해야 되는 경우 애너테이션을 사용할 수 밖에 없습니다. 마커 인터페이스를 적용해야 한다면 "마킹이 된 객체를 매개변수로 받는 메서드를 작성할 일이 있을까?"라고 자문해보는 게 좋습니다. 만약 그렇다라고 결론이 날 경우 마커 인터페이스를 사용하고 그렇지 않으면 마커 애너테이션을 사용하는 것이 더 나은 선택이 될 것입니다.


--------------------------------------------------------------------------------
/chap07/Item42.md:
--------------------------------------------------------------------------------
 1 | # [Item 42] 익명 클래스보다는 람다를 사용하라.
 2 | 
 3 | 자바 8부터는 함수형 프로그래밍을 지원합니다. 추상 메서드가 하나인(Single Abstract Method)인터페이스를 함수형 인터페이스라고 부르며 람다식을 사용해 만들 수 있습니다. 람다는 익명클래스에 비해 코드가 간결하고 가독성이 좋다는 장점이 있습니다.
 4 | 
 5 | ``` java
 6 | // 익명 클래스 방식
 7 | Collections.sort(words, new Comparator<String>() {
 8 |     @Override
 9 |     public int compare(String s1, String s2) {
10 |         return Interget.compare(s1.length(), s2.length());
11 |     }
12 | });
13 | ```
14 | ``` java
15 | // 람다 활용
16 | Collections.sort(words, 
17 |     (s1, s2) -> Integer.compare(s1.length(), s2.length()));
18 | ```
19 | 컴파일러가 타입을 추론해주기 때문에 타입을 명시해야 코드가 더 명확해질 때만 제외하고는, 람다의 매개변수 타입은 생략해줍시다. 혹시 컴파일러가 타입을 추론하지 못할경우에 명시해주면 됩니다.</br></br>
20 | 람다 자리에 메서드 참조를 활용하면 코드를 더 간결하게 만들어 줄 수 있습니다.
21 | > 문법:</br>
22 | > 클래스이름::메소드이름</br>
23 | > 또는</br>
24 | > 참조변수이름::메소드이름
25 | 
26 | ``` java
27 | Collections.sort(words, comparing(String::length));
28 | ```
29 | 
30 | 더 나아가 자바 8 때 List 인터페이스에 추가된 sort 메서드를 이용하면 더욱 짧아집니다.
31 | 
32 | ``` java
33 | words.sort(comparing(String::length));
34 | ```
35 | 
36 | 람다를 사용해서 코드 자체로 동작이 명확히 설명되지 않거나, 코드가 더 장황해질 경우 람다를 사용하지 말아야 합니다. 람다는 세 줄안에 끝내는 게 좋습니다.람다가 길거나 읽기 불편하면 리팩터링을 시도하길 추천합니다.
37 | </br>
38 | 람다는 함수형 인터페이스에서만 쓰입니다. 예컨대 인터페이스의 추상메서드가 한 개가 넘어가면 람다를 사용할 수 없습니다. 또 람다는 자신을 참조할 수 없습니다. 람다에서 `this` 키워드는 바깥 인스턴스를 가리킵니다.
39 | 


--------------------------------------------------------------------------------
/chap07/Item43.md:
--------------------------------------------------------------------------------
 1 | # [Item 43] 람다보다는 메서드 참조를 사용하라.
 2 | 
 3 | 메서드 참조를 이용하면 람다보다 간단하게 코드를 작성할 수 있습니다. 
 4 | 
 5 | > 문법 </br>
 6 | > 클래스이름::메소드이름</br>
 7 | > 또는</br>
 8 | > 참조변수이름::메소드이름
 9 | 
10 | 다음의 예제 코드는 키가 맵에 없다면 키와 숫자 1을 매핑하고, 이미 있다면 기존 매핑 값에 1을 증가시킵니다.
11 | 
12 | ``` java
13 | map.merger(key, 1, (count, incr) -> count + incr);
14 | ```
15 | 위 코드는 `Integer`의 `sum`메서드를 이용해서 대체할 수 있으며 메서드 참조를 이용해 간결하게 표현할 수 있습니다.
16 | 
17 | 
18 | ``` java
19 | map.merger(key, 1, Integer::sum);
20 | ```
21 | 
22 | 메서드 참조를 이용하면 코드가 간결해지며 가독성이 좋아지는 경우가 있지만 때로는 람다에서는 매개변수의 이름으로 가이드를 할 수도 있고 메서드 참조보다 더 읽기 쉽고 가독성이 더 좋아지는 경우가 있습니다.</br> </br>
23 | 메서드 참조 유형은 다섯가지가 있습니다. 가장 흔한 유형은 앞에서 사용했던 정적 메서드를 가리키는 메서드 참조입니다. 먼저 인스턴스 메서드를 참조하는 유형이 두 가지가 있습니다. 그 중 하나는 수신 객체(receiving object; 참조 대상 인스턴스)를 특정하는 한정적(bound) 인스턴스 참조이고, 다른 하나는 수신 객체를 특정하지 않는 비한정적(unbound) 인스턴스 메서드 참조압니다. 한정적 참조는 함수 객체가 받는 인수와 참조되는 메서드가 받는 인수와 똑같습니다. 비한정적 참조에서는 함수 객체를 적용하는 시점에 수신 객체를 알려줍니다. 이를 위해 수신 객체 전달용 매개변수가 매개변수의 목록의 첫 번째로 추가되며, 그 뒤로는 참조되는 메서드 선언에 정의된 매개변수들이 뒤따릅니다. 비한정적 참조는 스트림 파이프라인에서의 매핑과 필터 함수에 주로 사용됩니다.


--------------------------------------------------------------------------------
/chap07/Item44.md:
--------------------------------------------------------------------------------
1 | # [Item 44] 표준 함수형 인터페이스를 사용하라.
2 | 
3 | **java.util.function** 패키지에 다양한 용도의 표준 함수형 인터페이스가 정의되어 있으므로 용도에 맞는 게 있다면 직접 구현하지 말고 표준 함수형 인터페이스를 활용합시다. 일관성을 높일 수 있고 디폴트 메서드를 많이 제공하므로 다른 코드와의 상호운용성도 증가할 것입니다. java.util.function에는 총 43개의 인터페이스가 있지만 기본 인터페이스 6개만 기억하면 나머지는 충분히 유추할 수 있으며 나머지는 필요할 때마다 찾아서 사용하면 됩니다.
4 | </br>
5 | 표준 함수형 인터페이스 대부분은 기본 타입만 지원합니다. 그렇다고 기본 함수형 인터페이스에 박싱된 기본 타입을 넣어서 사용하지 맙시다. 동작은 하지만 계산량이 많을 때 성능 이슈가 생길 수 있습니다.</br>
6 | 표준 함수형 인터페이스 중 필요한 용도에 맞는 게 없다면 물론 함수형 인터페이스를 직접 작성해야 합니다. 다만 주의할 점이 함수형 인터페이스에는 항상 `@FunctionalInterface` 애너테이션을 사용해야 합니다. 누군가 실수로 추상 메서드를 하나 더 만드는 것을 방지해줄 수 있기 때문입니다.


--------------------------------------------------------------------------------
/chap07/Item45.md:
--------------------------------------------------------------------------------
 1 | # [Item 45] 스트림은 주의해서 사용하라.
 2 | 
 3 | 스트림이 제공하는 핵심 개념 중 핵심은 두 가지로 나눌 수 있습니다.
 4 | - 스트림은 데이터 원소의 유한 혹은 무한 시퀀스를 뜻합니다.
 5 | - 스트림 파이프라인은 이 원소들로 수행하는 연산 단계를 표현하는 개념입니다.
 6 | 
 7 | 스트림은 소스 스트림으로 시작해서 종단(최종) 연산(terminal operation)으로 끝나며, 그 사이에 하나 이상의 중간 연산자가 있을 수 있습니다. 중간 연산자는 어떠한 방식으로 변환(transform) 합니다. 최종 연산은 원소를 정렬해 컬렉션에 담거나, 특정 원소 하나를 선택하거나, 모든 원소를 출력하는 식입니다.
 8 | </br></br>
 9 | 스트림 파이프 라인은 **lazy**합니다. 최종 연산자가 호출 되기 전까지 실행하지 않습니다. 최종 연산에 쓰이지 않는 데이터 원소는 계산에 쓰이지 않습니다. 이러한 지연 평가는 무한 스트림을 다룰 수 있게 해줍니다. 최종 연산이 없는 스트림은 아무일도 하지 않으니(NOP) 빼먹는 일이 없도록 합시다.
10 | </br></br>
11 | 스트림 API는 파이프라인 하나를 구성하는 모든 호출을 연결하여 단 하나의 표현식으로 완성할 수 있습니다. 스트림을 이용해서 다양한 기능을 구사할 수 있지만, 잘못 사용하면 읽기 어려워지고 유지보수 하기도 힘들어집니다. </br>
12 | 스트림을 ㅊ처음 사용하면 모든 반복문을 스트림으로 바꾸고 싶겠지만, 신중하게 생각해봐야 합니다. 가독성과 유지보수, 메모리 측면에서 손해를 볼 수 있기 때문입니다.
13 | </br>
14 | 스트림 파이프라인에서 계산을 함수 객체로 표현하는데 함수 객체로는 할 수 없지만 코드 블록으로 할 수 있는 일들이 있습니다.
15 | 
16 | - 코드 블록에서는 범위 안의 지역변수를 읽고 수정할 수 있습니다. 하지만 람다에서는 final이거난 effective final만 읽을 수 있고, 지역변수를 수정할 수 없습니다.
17 | - 코드 블록에서는 return문을 사용해 메서드에서 빠져나가거나, break나 continue 문으로 블록 바깥의 반복문을 종료하거나 반복문을 한 번 건너뛸 수 있습니다. 또한 메서드 선언에 명시된 검사 예외를 던질 수 있습니다. 하지만 람다로는 이 중 어떤것도 할 수 없습니다.
18 | 
19 | 계산 로직에서 이상의 일들을 수행을 한다면 스트림과는 맞지 않는 것입니다. 다음은 스트림과 안성 맞춤인 일들 입니다.
20 | - 원소들의 시퀀스를 일관되게 변환한다.
21 | - 원소들의 시퀀스를 필터링한다.
22 | - 원소들의 시퀀스를 하나의 연산을 사용해 결합한다.
23 | - 원소들의 시퀀스를 컬렉션에 모은다.
24 | - 원소들의 시퀀스에서 ㅌ특정 조건을 만족하는 원소를 찾는다.
25 | 
26 | 


--------------------------------------------------------------------------------
/chap07/Item46.md:
--------------------------------------------------------------------------------
 1 | # [Item 46] 스트림에서는 부작용이 없는 함수를 사용하라.
 2 | 
 3 | 스트림 패러다임의 핵심은 계산을 일련의 변환으로 재구성하는 부분입니다. 이때 각 변환 단계는 가능한 한 이전 단계의 결과를 받아 처리하는 순수 함수여야 하는데, 순수 함수란 입력만이 결과에 영향을 주는 함수를 말합니다. 즉 다른 가변 상태를 참조하지 않고, 함수 스스로도 다른 상태를 변경하지 않습니다.</br>
 4 | 다음은 텍스트 파일에서 단어별 수를 세어 빈도표를 만드는 코드입니다.
 5 | 
 6 | ``` java
 7 | // 스트림을 이해하지 못한 코드 - 따라 하지 말 것
 8 | Map<String, Long> freq = new HashMap<>();
 9 | try (Stream<String> words = new Scanner(file).tokens()) {
10 |     words.forEach(word -> {
11 |         freq.merge(word.toLowerCase(), 1L, Long::sum)
12 |     });
13 | }
14 | ```
15 | 스트림 API의 이점을 살리지 못한 코드입니다. 같은 기능의 반복 코드보다 읽기 어렵고, 유지 보수도 어렵습니다. 심지어 `forEach`에서는 람다가 상태를 수정하기도 합니다.
16 | 
17 | ``` java
18 | // 스트림을 제대로 할용한 예
19 | Map<String, Long> freq = new HashMap<>();
20 | try (Stream<String> words = new Scanner(file).tokens()) {
21 |    freq = words
22 |         .collect(groupingBy(String::toLowerCase, counting()));
23 | }
24 | ```
25 | `forEach` 연산은 스트림 결과를 보고할 때만 사용하고, 계산할 때는 사용하지 맙시다.
26 | </br>
27 | 다음 코드는 빈도표에서 가장 흔한 단어 10개를 뽑아내는 파이프라인 입니다.
28 | 
29 | ``` java
30 | // Collectors 정적 임포트를 활용해 코드가 짧아지고 가독성을 향상시켰습니다.
31 | List<String> toTen = freq.keySet().stream()
32 |     .sorted(comparing(freq::get).reversed())
33 |     .limit(10)
34 |     .collect(toList());
35 | ```
36 | 이번엔 `Collectors`의 메서드 기능을 알아보겠습니다. 가장 간단한 맵 수집기로 toMap(keyMapper, valueMapper)가 있습니다.
37 | 
38 | ``` java
39 |     Map<String, String> listToMap = books.stream()
40 |         .collect(toMap(Book::getIsbn, Book::getName));
41 | ```
42 | 다수의 키가 존재한다면 IllegalStateException을 던지며 종료합니다.</br>
43 | 인수를 3개 받는 toMap은 어떤 키와 그 키에 연관된 연관된 원소들 중 하나를 골라 연관짓는 맵을 만들때 유용합니다. 다음 코드는 음악가와 그 음악가의 베스트 앨범을 연관짓고 싶은 일을 수행합니다.
44 | 
45 | ``` java
46 | Map<Artist, Album> toHits = albums.collect(
47 |     toMap(Album::artist, artist -> artist, maxBy(Comparing(Album::sales)));
48 | )
49 | ```
50 | 
51 | 인수 3개를 받는 toMap도 있습니다. 어떤 키와 그 키에 연관된 원소들 중 하나를 골라 연관짓는 맵을 만들때 유용합니다. 다음 코드는 음악가의 베스트 앨범을 연관짓는 Map을 만드는 코드입니다.
52 | 
53 | ``` java
54 | Map<Artist, Album> toHits = albums.collect(
55 |     toMap(Album::airtst, a -> a, maxBy(comparing(Album::sales)));
56 | )
57 | ```
58 | 
59 | `groupingBy` 메서드는 입력으로 분류 함수(classifier)를 받고 출력으로는 원소들을 카테고리별로 모아놓은 맵을 담은 수집기를 반환합니다. 분류 함수는 입력받은 원소가 속하는 카테고리를 반환합니다. groupingBy 함수의 가장 간단한 것은 분류 함수 하나를 인수로 받아 맵으로 반환하는 것입니다.
60 | ``` java
61 | // ISBN을 key값으로 갖는 맵의 형태입니다.
62 | Map<String, List<Book>> collect = books.stream()
63 |     .collect(groupingBy(Book::getIsbn));
64 | ```
65 | 인수를 두개 갖는 `groupingBy`함수는 다운스트림 수집기도 함께 명시해야 합니다. 다운 스트림 수집기의 역할은 해당 카테고리의 모든 원소를 담은 스트림으로 부터 값을 생성하는 것입니다. 그 다음 인수를 3개 받는 메서드도 있는데 맵 팩터리도 지정할 수 있습니다.


--------------------------------------------------------------------------------
/chap07/Item47.md:
--------------------------------------------------------------------------------
 1 | # [Item 47] 반환 타입으로는 스트림보다 컬렉션이 낫다.
 2 | 
 3 | 사실 `Stream` 인터페이스 `Iterable` 인터페이스가 정의한 추상 메서드를 전부 포함하고 Iterable 인터페이스가 정의한 방식대로 동작합니다. 하지만 for-each로 스트림을 반복할 수 없는 이유는 Stream이 Iterable을 확장하지 않아서입니다.
 4 | </br>
 5 | `Collection`인터페이스는 Iterable의 하위 타입이고 stream의 메서드도 제공하니 반복과 스트림을 동시에 지원합니다. 따라서 원소 시퀀수를 공개하는 공개 API의 반환타입에는 Collection이나 그 하위 타입을 사용하는게 일반적으로 좋습니다.
 6 | 
 7 | ### 정리
 8 | - 원소 시퀀스를 반환하는 메서드를 작성할 때는, 이를 스트림으로 처리하길 원하는 사용자와 반복으로 처리하길 원하는 사용자가 모두 있을 수 있음을 고려하라
 9 | - 컬렉션을 반환할 수 있다면 그렇게 하고 반환 전부터 이미 원소들을 컬렉션에 관리하고 있거나 컬렉션을 하나 더 만들어도 될 정도로 원소 개수가 적다면 ArrayList같은 표준 컬렉션에 담아 반환하라.
10 | 
11 | 


--------------------------------------------------------------------------------
/chap07/Item48.md:
--------------------------------------------------------------------------------
 1 | # [Item 48] 스트림 병렬화는 주의해서 적용하라.
 2 | 
 3 | 자바 8에 추가된 `parallel` 메서드는 파이프라인을 병렬 실행할 수 있습니다. 동시성 프로그래밍을 할 때는 안전성과 응답 가능 상태를 유지하기 위해 주의를 기울여야합니다. **데이터 소스가 Stream.iterate거나 중간 연산으로 limit를 쓰면 파이프라인 병렬화로 성능 개선을 기대할 수 없습니다.** </br>
 4 | 대체로 스트림 소스가 `ArrayList`, `HashMap`, `HashSet`, `ConcurrentHashMap`의 인스턴스거나 배열, int 범위, long 범위일 때 병렬화의 효과가 가장 좋습니다. 이 자료구조들은 데이터를 원하는 크기로 정확하고 손쉽게 나눌 수 있어서 다수의 스레드에 분배하기 좋다는 특성이 있습니다. 나누는 작업은 `Spliterator`가 담당하고 Spliterator 객체는 Stream이나 Iterable의 spliterator 메서드로 얻어올 수 있습니다. 또한 원소들을 순차적으로 실행할 때 **참조 지역성(locality of reference)** 가 뛰어납니다.</br></br>
 5 | 참조 지역성이란 이웃한 원소의 참조들이 메모르에 연속해서 저장되어 있다는 뜻입니다. 만일 참조들이 가리키는 실제 객체가 메모르에 서로 떨어져 있을 경우 참조 지역성이 나빠집니다. 참조 지역성이 낮으면 스레드는 데이터가 주 메모르에서 캐시 메모리로 전송되어 오기를 기다리며 시간을 보내게 됩니다. </br>
 6 | 참조 지역성이 가장 뛰어난 자료구조는 기본 타입의 배열인데 이는 데이터 자체가 메모리에 연속해서 저장되기 때문입니다.</br>
 7 | 스트림 파이프라인의 최종 연산의 동작 역시 병렬 수행 효율에 영향을 줍니다. 최종 연산 중 병렬화에 가장 적합한 것은 축소입니다. Stream의 reduce 메서드 중 하나 혹은 min, max, sum, count 같이 완성된 형태로 제공되는 메서드를 선택해 수행합니다. anyMatch, allMatch, noneMath처럼 조건에 맞으면 바로 반환되는 메서드도 병렬화에 적합합니다. 반면 가변 축소를 수행하는 Stream의 collect 메서드는 병렬화에 적합하지 안흔데 이는 컬렉션들을 합치는 부담이 크기 때문입니다.
 8 | </br>
 9 | </br>
10 | 
11 | 스트림을 잘못 정렬화하면 결과 자체가 달라지거나 예상치 못한 동작이 발생할 수 있습니다. 이를 안전 실패라 부릅니다. 안전 실패는 스트림 파이프라인에서 사용하는 mapper, filters 혹은 프로그래머가 제공한 다른 함수 객체가 명세대로 동작하지 않을 때 벌어질 수 있습니다.
12 | 
13 |  


--------------------------------------------------------------------------------
/chap08/Item49.md:
--------------------------------------------------------------------------------
1 | # 매개변수가 유효한지 검사하라.
2 | 
3 | 메서드와 생성자는 대부분 특정 조건의 입력 매개변수에 특정 조건을 만족하기를 바랍니다. 만일 잘못된 값이 들어올 경우 보통 예외를 던지거나 컴파일 오류를 잡아내긴 하지만, 오류는 가능한 빨리 잡아내는 게 좋습니다. 그렇지 않으면 감지하기 어려워지고 감지하더라도 찾아내기 힘들어지는 경우도 있습니다.</br>
4 | 이러한 경우를 방지하기 위해 매개변수를 미리 확인한다면 즉각적이고 깔끔한 방식으로 예외를 처리할 수 있습니다.
5 | </br>
6 | 하지만 반드시 메서드를 실행하기 전에 매개변수 유효성 검사를 해야하는 것만은 아닙니다. 유효성 검사 비용이 지나치게 높거나 실용적이지 않을 때는 다시 고려를 해봐야 합니다.</br>
7 | 이번 아이템의 핵심은 "매개변수에 제약을 두는 게 좋다"라는 것이 아닙니다. 메서드는 최대한 범용적으로 설계해야 합니다. 메서드가 건네 받은 값으로 어떠한 제대로 된 일을 할 수 있다면 제약이 적을 수록 좋습니다. 이러한 요소들을 잘 고려해서 상황에 맞게 사용해야합니다.


--------------------------------------------------------------------------------
/chap08/Item50.md:
--------------------------------------------------------------------------------
 1 | # [Item50] 적시에 방어적 복사본을 만들라
 2 | 
 3 | 이번 아이템에서는 지난 Item17에 다루었던 불변에 대한 주제가 포함되어있습니다. 어떤 객체든 객체의 허락 없이는 외부에서 함부로 내부를 수정하게 하는 일이 없아야 합니다. 하지만 주의를 기울이지 않으면 자신도 모르게 내부를 수정하도록 코드를 짜는 경우가 생길 수 있습니다.
 4 | </br>
 5 | 다음은 부주의로 일어날 수 있는 상황을 예시로 든 코드입니다.
 6 | 
 7 | ``` java
 8 | public final class Period {
 9 |     private final Date date;
10 |     private final Date end;
11 | 
12 |     public Period(Date start, Date end) {
13 |         if (start.compareTo(end) > 0) {
14 |             throw new IllegalArgumentException(start + "가" + end + "보다 늦다.");
15 |         }
16 |         this.start = start;
17 |         this.end = end;
18 |     }
19 | 
20 |     public Date start() {
21 |         return start;
22 |     }
23 | 
24 |     public Date end() {
25 |         return end;
26 |     }
27 | }
28 | ```
29 | 
30 | 불변을 의도하고 설계한 코드입니다. 하지만 `Date`가 mutable 하다는 사실을 이용하여 이 불변을 쉽게 깨뜨릴 수 있습니다.
31 | 
32 | ``` java
33 | Date start = new Date();
34 | Date end = new Date();
35 | Period p = new Period(start, end);
36 | end.setYear(100); // p의 내부를 수정했다
37 | ```
38 | 이러한 문제점을 해결하기 위해 자바 8에서는 `java.time` 패키지를 지원합니다. 하지만 기존 레거시 프로젝트에 `Date`는 여전히 많이 남아있습니다. 이번에 소개해드릴 방법은 이러한 레거시 코드들을 대처하기 위함입니다. 외부로부터 `Period` 인스턴스의 내부를 보호하려면 생성자에게 받은 가변 매개변수 각각을 방어적으로 복사해야합니다. 그런 다음 Period 인스턴스 안에서는 원본이 아닌 복사본을 사용해야 합니다.
39 | 
40 | ``` java
41 | // 수정한 생성자 - 매개변수의 방어적 복사본을 만듦
42 | public Period(Date start, Date end) {
43 |     this.start = new Date(start.getTime());
44 |     this.end = new Date(end.getTime());
45 | 
46 |     if (this.start.compareTo(this.end) > 0) {
47 |         throw new IllegalArgumentException(start + "가" + end + "보다 늦다.");
48 |     }
49 | }
50 | ```
51 | 이 방법을 이용하면 방금의 방식으로 값을 바꾸려고하는 걸 막을 수 있습니다. 매개변수의 유효성을 검하기 전에 방어적 복사본을 만들고, 이 복사본으로 유혀성을 검사한다는 점에 주목해야합니다. 하지만 아직도 Period 객체는 변경 가능합니다. 접근자 메서드가 내부의 가변 정보를 직접 드러내기 떄문입니다.
52 | 
53 | ``` java
54 | Date start = new Date();
55 | Date end = new Date();
56 | Period p = new Period(start, end);
57 | p.end().setYear(100); // p의 내부를 변경했다.
58 | ```
59 | 
60 | 이 공격을 막아내려면 단순히 접근자가 가변 필드의 방어적 본사본을 반환하거나 `setter`를 제공하지 않으면 됩니다.
61 | 
62 | ``` java
63 | public Date start() {
64 |     return new Date(start.getTime());
65 | }
66 | 
67 | public Date end() {
68 |     return new Date(end.getTime());
69 | }
70 | ```
71 | 
72 | 이제 Period는 완벽한 불변으로 거듭납니다. 메서드든 생성자든 클라이언트가 제공한 객체의 참조를 내부의 자료구조에 보관해야 할 때면 항시 그 객체가 잠재적으로 변경될 수 있는지를 생각해야합니다. 방어적 복사에는 성능 저하가 따른다는 것도 명심해야하고 되도록 불변 객체들을 조합해 객체를 구성해야 방어적 복사를 할 일이 줄어듭니다.


--------------------------------------------------------------------------------
/chap08/Item51.md:
--------------------------------------------------------------------------------
 1 | # [Item 51] 메서드 시그니처를 신중히 설계하라.
 2 | 
 3 | ### 메서드 이름을 신중히 짓자.
 4 | 항상 표준 명명 규칙을 따라야합니다. 이름만 보고 이해할 수 있고, 일관성있게 짓는 것이 핵심입니다. 그 다음 목표는 개발자 커뮤니티에서 널리 받아들여지는 이름을 사용하는 것입니다. 되도록이면 긴 이름은 피하는 것이 좋습니다. 물론 조직내에 규율이 있다면 그 규율을 지키는 게 우선입니다.
 5 | 
 6 | ### 편의 메서드를 너무 만들지 말자.
 7 | 메서드가 너무 많은 클래스는 파악하고 유지보수 하기도 힘들고 객체지향 SOLID원칙 중 **Single Responsiblity Principle**에 위반될 수도 있습니다.
 8 | 
 9 | ### 매개변수 목록은 짧게 유지하자.
10 | 가능한 4개 이하가 좋습니다. 물론 IDE를 이용하면 수고를 덜 수 있지만, 매개변수 수는 적은 쪽이 훨씬 낫습니다. 같은 타입의 매개변수가 여러 개 나오는 경우가 특히 해롭습니다. 실수로 순서를 바꿔서 입력해도 그대로 컴파일은 되고 실행되기 때문에 런타임 시에 오작동이 될 수 있습니다.
11 | </br>
12 | 다음은 매개변수 목록을 짧게 줄여줄 세 가지 기술입니다.
13 | 1. 여러 메서드로 쪼갠다. 이 방법은 주의해서 사용합니다. 잘못할 경우 메서드가 너무 많아질 수가 있습니다. 하지만 잘 만들면 직교성을 높여 오히려 메서드 수를 줄여주는 효과도 있습니다. `List`인터페이스가 대표적인 예입니다. `subList`메서드와 `indexOf` 메서드를 적절하게 이용하면 지정된 범위의 부분리스트에서의 인덱스를 찾을 수 있습니다.
14 | 2. 두 번째는 매개변수 여러 개를 묶어주는 도우미 클래스를 만드는 것입니다. 일반적으로 이런 도우미 클래스는 정적 멤버 클래스로 둡니다. 
15 | 3. 앞서 두 개의 기법을 혼합한 것으로 객체 생성에 사용한 빌더 패턴을 메서드 호출에 응용한다고 보면 됩니다. 먼저 모든 매개변수를 하나로 추상화한 객체를 정의하고, 클라이언트에서 이 객체의 세터 메서드를 호출해 필ㅇ한 값을 설정하게 하는 것입니다. 매개변수 타입으로는 클래스보다는 인터페이스가 더 낫습니다. 예를들어 메서드에 ArrayList을 사용하지말고 Map을 사용하는 것입니다. 이 방식을 이용하면 유용성을 얻을 수 있습니다.
16 |    


--------------------------------------------------------------------------------
/chap08/Item52.md:
--------------------------------------------------------------------------------
 1 | # [Item 52] 다중정의는 신중히 사용하라.
 2 | 
 3 | 다음은 컬렉션을 집합, 리스트, 그 외로 구분하고자 만든 프로그램입니다.
 4 | 
 5 | ``` java
 6 | public class CollectionClassifier {
 7 |     public static String classify(Set<?> s) {
 8 |         return "Set";
 9 |     }
10 |     public static String classify(List<?> lst) {
11 |         return "List";
12 |     }
13 |     public static String classify(Collection<?> c) {
14 |         return "Unknown Collection";
15 |     }
16 |     public static void main(String[] args) {
17 |         Collection<?>[] collections = {
18 |             new HashSet<String>(),
19 |             new ArrayList<BigInteger>(),
20 |             new HashMap<String, String>().values()
21 |         };
22 |         for (Collection<?> c : collections)
23 |             System.out.println(classify(c));
24 |     } 
25 | }
26 | ```
27 | "Set", "List", "Unknown Collection" 차례대로 출력될 거 같지만, 실제로 수행하면 "Unknown Collection"만 연달아 세 번 출력됩니다. 이유는 오버로딩된 세 classify 증 어느 메서드를 호출할 지가 컴파일 타임에 정해지기 때문입니다. 컴파일 타임에서 for문 안에 c타입은 항상 `Collection<?>`타입 입니다. 런타임 시에는 달라지지만, 호출할 메서드를 선택하는 데는 영향을 주지 못합니다.
28 | </br>
29 | </br>
30 | 이처럼 직관에 어긋나는 이유는 **재정의한 메서드는 동적으로 선택되고, 다중정의한 메서드는 정적으로 선택되기 때문입니다.** 메서드를 재정의 한 다음 하위클래스의 인스턴스에서 그 메서드를 호출하면 재정의한 메서드가 실행됩니다. 컴파일 타임에 그 인스턴스 타입이 무엇인지는 상관 없습니다. </br>
31 | 다음 코드는 이러한 상황을 구체적으로 보여주는 예시입니다.
32 | 
33 | ``` java
34 | class Wine {
35 |   String name() {
36 |     return "wine";
37 |   }
38 | }
39 | 
40 | class SparklingWine extends Wine {
41 |   @Override
42 |   String name() {
43 |     return "sparkling wine";
44 |   }
45 | }
46 | 
47 | class Champagne extends SparklingWine {
48 |   @Override
49 |   String name() {
50 |     return "champagne";
51 |   }
52 | }
53 | 
54 | class Overriding {
55 |   public static void main(String[] args) {
56 |     List<Wine> wineList = Arrays.asList(
57 |         new Wine(), new SparklingWine(), new Champagne());
58 | 
59 |     for (Wine wine : wineList) {
60 |       System.out.println(wine.name());
61 |     }
62 |   }
63 | }
64 | ``` 
65 | `Wine`클래스에서 정의한 name메서드를 각각 서브타입에서 재정의 했습니다. 이 코드를 실행하면 아까와는 달리 "wine","sparkling wine", "champagne"이 차례대로 출력됩니다. 컴파일 타임 타입이 모두 Wine인 것에 무관하게 항상 가장 하위에서 재정의한 메서드가 실행됩니다.</br>
66 | </br>
67 | 한편 다중정의된 메서드 사이에서는 객체의 런타임 타입은 전혀 중요하지 않습니다. 선택은 컴파일 타임에, 오직 매개변수의 컴파일 타임 타입에 의해 이뤄집니다. 앞서 의도대로 동작하지 않았던 classify 메서드는 하나로 합친 후 instanceof를 이용하면 원하는 데로 동작하게 변경할 수 있습니다.
68 | </br>
69 | 다중정의를 안전하고 보수적으로 사용하려면 매개변수 수가 같은 다중정의는 만들지 않는 게 좋습니다. 다중정의 하는 대신 메서드 이름을 다르게 지어주는 경우도 고려해볼 수 있습니다. 대표적인 예로 `ObjectOutputStream`클래스의 write 메서드가 그러합니다.
70 | 
71 | </br></br>
72 | 자바 4까지는 기본 타입이 모든 참조 타입이랑 근본적으로 달랐지만, 자바 5에서 부터 오토박싱이 도입되면서 문제가 생긴 부분이 있습니다. 대표적으로 `List` 인터페이스의 `remove`메서드가 그러합니다. remove메서드는 int를 받는 메서드와 Object를 매개변수로 받는 메서드로 다중정의 되어 있습니다. 물론 자바 4까지는 문제가 없었지만 오토박싱이 생기면서 혼란을 안겨주고 List인터페이스가 취약해졌습니다.
73 | 


--------------------------------------------------------------------------------
/chap08/Item53.md:
--------------------------------------------------------------------------------
 1 | # [Item 53] 가변인수는 신중히 사용하라.
 2 | 
 3 | 가변인수(varargs) 메서드는 명시한 타입의 인수를 0개 이상 받을 수 있습니다. 다음 예제는 int 인자의 합을 구하는 가변인수 메서드입니다.
 4 | 
 5 | ``` java
 6 | static int sum(int... args) {
 7 |     int sum = 0;
 8 |     for (int args: args) {
 9 |         sum += args;
10 |     }
11 |     return sum;
12 | }
13 | ```
14 | 
15 | 1개 이상의 인수가 필요한 경우도 있습니다. 다음 예제는 1개 이상의 인수를 필요료하는 가변인수 메서드의 잘못된 구현입니다.
16 | 
17 | ``` java
18 |   static int sum(int... args) {
19 |     if (args.length == 0) {
20 |       throw new IllegalArgumentException("인수가 1개 이상 필요합니다.");
21 |     }
22 |     int min = args[0];
23 |     for (int arg : args)
24 |       if (arg < min)
25 |         min = arg;
26 |     return min;
27 |   }
28 | ```
29 | 이 방식에는 몇 가지 문제점이 있습니다. 가장 큰 문제는 인수를 0개만 넣으면 **런타임** 시점에 실패한다는 것입니다. 코드도 지저분합니다.</br>
30 | 다음 코드는 매개변수를 2개를 받아서 이 문제를 해결하는 방식입니다.
31 | 
32 | ``` java
33 | static int min(int firstArg, int... remainingArgs) {
34 |     int min = firstArg;
35 |     for (int arg : remainingArgs) {
36 |         if (arg < min)
37 |             min = arg
38 |     }
39 |     return min;
40 | }
41 | ```
42 | 가변인수를 사용하면서 주의할 점이 있습니다. 가변인수 메서드는 호출될 때마다 배열을 새로 하나 할당하고 초기화기 때문에 성능에 민감할 경우 조심히 주의해서 사용해야합니다. 기변인수 메서드의 유용성을 활용하고 싶고 성능에 민감할 경우 다른 방식을 이용할 수 있습니다. 예를 들어 해당 메서드 호출의 95%가 인수 3개 이하로 사용한다고 하면 다음처럼 0개인 것부터 4개인 것까지, 총 5개를 정의해서 사용할 수 있습니다.
43 | 
44 | ``` java
45 |    public void foo() { }
46 |    public void foo(int a1) { }
47 |    public void foo(int a1, int a2) { }
48 |    public void foo(int a1, int a2, int a3) { }
49 |    public void foo(int a1, int a2, int a3, int... rest) { }
50 | ```
51 | 
52 | `EnumSet`의 정적 팩터리도 이 기법을 사용해 열거 타입 집합 생성 비용을 최소화 합니다.


--------------------------------------------------------------------------------
/chap08/Item54.md:
--------------------------------------------------------------------------------
 1 | # [Item 54] null이 아닌, 빈 컬렉션이나 배열을 반환하라.
 2 | 
 3 | ``` java
 4 | // 컬렉션이 비어있으면 null을 반환 - 따라하지 말 것
 5 | private final List<Cheese> cheesesInStock = ...;
 6 | 
 7 | public List<Cheese> getCheeses() {
 8 |     return cheesesInStock.isEmpty() ? null : new ArrayList<>(cheesesInStock);
 9 | }
10 | ```
11 | 
12 | null을 반환할 경우 클라이어트는 이 null 상황을 처리하는 코드를 추가로 작성해야합니다.
13 | 
14 | ``` java
15 | List<Cheese> cheesesInStock = shop.getCheeses();
16 | if (cheese != null && cheeses.contains(cheese.STILTON)) {
17 |     system.out.println("좋았어, 바로 그거야!")
18 | }
19 | ```
20 | 
21 | 클라이언트에서 null을 처리하는 코드를 빼먹으면 오류가 발생할 수 있으며 코드가 장황해집니다. 때로는 빈 컨테이너를 할당하는 데 비용이 드니 null을 반환하는 게 낫다는 주장도 있습니다. 하지만 이 주장은 두가지 측면에서 틀립니다.</br>
22 | 첫 번째. 성능 분석 결과 이 할당이 성능 저하의 주범이라고 확인되지 않는 한, 이 정도의 성능 차이는 신경 쓸 수준이 못됩니다. </br>
23 | 두 번째 빈 컬렉션과 배열은 굳이 새로 할당하지 않고도 반환할 수 있습니다.
24 | 
25 | ``` java
26 | // 빈 컬렉션을 반환하는 올바른 예
27 | public List<Cheese> getCheese() {
28 |     return new ArrayList<>(cheeseInStock);
29 | }
30 | ```
31 | 
32 | 매번 똑같이 빈 불변 컬렉션을 반환하는 방식으로 성능 이슈도 해결할 수 있습니다. **Collections.emptyList**가 메서드가 대표적인 예입니다. 집합이 필요하면**Collections.emptySet**을, 맵이 필요하면 **Collections.emptyMap**을 사용하면 됩니다. 최적화가 필요하다고 판단되면 사용 전과 후를 측정해보고 사용할 것을 추천합니다.
33 | 
34 | ``` java
35 | public List<Cheese> getCheese() {
36 |     return cheeseInStock.isEmpty() ? Collections.emptyList() : new ArrayList<>(cheeseInStock);
37 | }
38 | ```
39 | 
40 | 배열을 사용할 때도 마찬가지입니다. null을 반환 하지 말고 길이기 0인 배열을 반환하면 됩니다.
41 | 
42 | ``` java
43 | public Cheese[] getCheeses() {
44 |     return cheesesInStock.toArray(new Cheese[0]);
45 | }
46 | ```
47 | 이 방식에서 성능을 더 개선할 수 있는 방법이 있습니다. 길이가 0짜리 배열을 미리 선언해두고 반환하면 됩니다.
48 | ``` java
49 | private static final Cheese[] EMPTY_CHEESE_ARRAY = new Cheese[0];
50 |    public Cheese[] getCheeses() {
51 |        return cheesesInStock.toArray(EMPTY_CHEESE_ARRAY);
52 | }
53 | ```


--------------------------------------------------------------------------------
/chap08/Item55.md:
--------------------------------------------------------------------------------
1 | # [Item 55] 옵셔널 반환은 신중히 하라
2 | 
3 | 자바 8이전에는 메서드가 특정 값을 반환할 수 없을때 취할 수 있는 선택지가 두 가지가 있었습니다. 예외를 던지거나, null을 반환하는 것입니다. 두 방법 모두 허점이 있습니다. 예외는 진짜 예외적인 상황에서만 사용해야 하며 예외를 생성할 때 스택 추적 전체를 캡쳐하므로 바용도 만만치 않습니다. null을 반환할 수 있는 메서드를 호출하면 null 처리를 별도로 해줘야합니다. null 처리를 무시하면 나중에 NPE가 발생할 수 있습니다.
4 | </br></br>
5 | 자바 8부터는 `Optional`을 지원했습니다. `Optional<T>`는 null이 아닌 `T`타입 참조를 하나 담거나, 아무것도 담지 않을 수 있습니다. optional을 이용하면 예외를 던지느 메서드보다 더 유연하고, null을 반환하는 메서드보다 오류 가능성이 적습니다.
6 | 하지만 그렇다고 Optional을 남발해서는 안 됩니다. 대표적으로 컬렉션, 스트림, 배열, 옵셔널 같은 컨테이너 타입은 옵셔널로 반환하면 안 됩니다. 빈 컨테이너를 그대로 반환하면 클라이언트에 옵셔널 처리 코드를 넣지 않아도 됩니다.</br>
7 | Optional도 새로 할당하고 초기화해야 하는 객체이고, 그 안에서 값을 꺼내는 메서드를 호출하는 단계를 추가롤 거쳐야 합니다. 박싱된 기본 타입을 감싸는 Optional같은 경우 값을 두 번이나 감싸니 기본 타입보다 훨씬 무거울 수 밖에 없습니다. 그래서 `OptionalInt`, `OptionalLong`, `OptionalDouble`을 제공하니 박싱된 기본 타입을 담은 Optional은 사용하는 일이 없도록 합시다.


--------------------------------------------------------------------------------
/chap08/Item56.md:
--------------------------------------------------------------------------------
1 | # [Item 56] 공개된 API 요소에는 항상 문서화 주석을 작성하라.
2 | 
3 | javadocd이라는 유틸리티를 이용하면 소스코드 파일에서 문서화 주석이라는 특수한 형태로 기술된 설명을 추려 API 문서로 변환해줍니다.</br>
4 | 메서드용 문서화 주석에는 해당 메서드와 클라이어트 사이의 규약을 명료하게 기술해야 합니다. 핵심 포인트는 how가 아닌 what입니다. 무엇을 하는지에 대한 설명이 있어야 합니다. 또한 메서드를 호출하기위한 조건, 수행된 후에 만족해야 하는 사후조건, 부작용도 모두 나열되어야 합니다. 잘 쓰인 문서인지 확인하는 유일한 방법은 자바독 유틸리티가 생성한 웹페이지를 읽어보는 길뿐입니다.


--------------------------------------------------------------------------------
/chap09/Item57.md:
--------------------------------------------------------------------------------
 1 | # [Item 57] 지역변수의 범위를 최소화하라.
 2 | 
 3 | 지역변수의 범위는 가능한 좁히는 게 좋습니다. 가장 좋은 방법은 선언과 동사에 초기화 해주는 것입니다. 초기화에 필요한 정보가 없다면 정보가 주어질 때까지 선언을 미루는 것입니다.. 물론 `try-catch`문은 이 규칙에서 예외입니다. try 블록 안에서 초기화해야하고 밖에서도 쓰일 경우 try 블록 앞에서 선언해야 합니다.
 4 | </br>
 5 | 이러한 지역변수 초기화는 대표적으로 for (for-each), while로 비교할 수 있습니다.
 6 | 
 7 | ``` java
 8 | // 컬렉션이나 베열을 순회하는 권장 관용구
 9 | for (Element e : c) {
10 |     ...
11 | }
12 | ```
13 | 
14 | ``` java 
15 | //  빈복자가 필요한 때의 관용구
16 | for (Iterator<Element> i = c.iterator(); i.hasNext;) {
17 |     Elements e = i.next();
18 |     ...
19 | }
20 | ```
21 | 
22 | ``` java
23 | Iterator<Element> i = c.iterator();
24 | while (i.hasNext()) { // 버그
25 |     doSomething(i.next());
26 | }
27 | // while문 실수로 버그 발생
28 | Iterator<Element> i2 = c2.iterator();
29 | while (i.hasNext()) { // 버그
30 |     doSomething(i2.next());
31 | }
32 | ```
33 | 복사 붙여넣기를 하다가 실수로 i를 그대로 사용한 것입니다. i의 유효범위가 살아있어서 발생하는 일입니다. 이는 컴파일 오류도 잡지 못하고 런타임시 엉뚱한 결과를 초래할 수 있습니다. 이러한 일이 발생하지 않으려면 지역변수의 범위를 최소화 해야합니다.


--------------------------------------------------------------------------------
/chap09/Item58.md:
--------------------------------------------------------------------------------
 1 | # [Item 58] 전통적인 for 문보다는 for-each를 사용하라.
 2 | 
 3 | for 문은 코드가 장황해질 수 있고, 요소 종류가 늘어날 수록 오류가 생길 가능성이 있습니다. for-each (정식명칭 향상된 for문)은 이러한 단점들을 해결해줄 수 있습니다.  
 4 | 
 5 | ``` java
 6 | for (Element e : elements) {
 7 |     .... // e로 무언가를 한다.
 8 | }
 9 | ```
10 | 컬렉션을 중첩해서 사용하면 for-each 문의 이점은 더욱 커집니다.
11 | 
12 | ``` java
13 | // 버그를 찾아보자
14 | enum Suit { CLUB, DIAMOND, HEART, SPADE }
15 | enum Rank { ACE, DEUCE, THREE, FOUR, FIVE, SIX, SEVEN, EIGHT,
16 |             NINE, TEN, JACK, QUEEN, KING }
17 | ...
18 | 
19 | static Collection<Suit> suits = Arrays.asList(Suit.values());
20 | static Collection<Rank> ranks = Arrays.asList(Rank.values());
21 | 
22 | List<Card> deck = new ArrayList<>();
23 | for (Iterator<Suit> i = suits.iterator(); i.hasNext(); )
24 |     for (Iterator<Rank> j = ranks.iterator(); j.hasNext(); )
25 |         deck.add(new Card(i.next(), j.next()));
26 | ```
27 | 
28 | 마지막 줄에 i에서 문제가 발생합니다. i(무늬)가 j(숫자)당 하나씩만 부여되야하는데, i랑 j과 next로 함께 순회하고 있는 것입니다. 이 케이스에너느 결국  `NoSuchElementException`이 발생하게 됩니다.
29 | </br>
30 | 이러한 문제점들은 for-each문을 이용해서 간단하게 해결할 수 있습니다.
31 | 
32 | ``` java
33 |     for (Suit suit : suits)
34 |       for (Rank rank : ranks) {
35 |         deck.add(new Card(suit, rank));
36 |       }
37 |   }
38 | ```
39 | 
40 | 하지만 몬든 상황에서 for-each 문을 사용할 수 있는 건 아닙니다. 다음은 for-each 문을 사용할 수 없는 상황입니다.
41 | - 파괴적인 필터링: 컬렉션을 순회하면서 선택된 원소를 제거하려면 반복자의 remove 메서드를 호출해야 합니다. 자바 8부터는 Collection의 removeIf 메서드를 사용해 컬렉션을 명시적으로 순회하는 일을 피할수 있습니다.
42 | - 변형: 리시트나 배열을 순회하면서 그 원소의 값 일부 홋은 전체를 교체해야 한다면 반복자나 배열의 인덱스를 사용해야 합니다.
43 | - 병렬 반복: 여러 컬렉션을 병렬로 순회해야 한다면 각각의 반복자와 인덱스 변수를 사용해 엄격하고 명시적으로 제어해야 합니다.
44 | 
45 | 


--------------------------------------------------------------------------------
/chap09/Item59.md:
--------------------------------------------------------------------------------
 1 | # [Item 59] 라이브러리를 익히고 사용하라.
 2 | 
 3 | 0부터 명시한 수 까지 무작위 정수를 하나 생성하려고 합니다. 다음은 흔히 마주할 수 있는 문제있는 메서드입니다.
 4 | 
 5 | ``` java
 6 | static Random ran = new Randon();
 7 | 
 8 | static int random(int n) {
 9 |     return Math.abs(ran.nextInt()) % n;
10 | }
11 | ```
12 | 이 코드에는 세 가지 문제점이 있습니다. 첫 번째. n이 그리 크지 않은 2의 제곱수라면 얼마 지나지 않아 같은 수열이 반복됩니다. 두 번째, n이 2의 제곱수가 아니라면 몇몇 숫자가 평균적으로 더 반복됩니다. n값이 크면 이 현상은 더 두드러집니다.
13 | </br>
14 | 다음 코드는 선택한 버뮈에서 무작위 수를 백만개를 생성한 뒤, 그 중 중간 값보다 작은 게 몇 개인지를 출력합니다.
15 | 
16 | ``` java
17 | public static void main(String[] args) {
18 |     int n = 2 * (Integer.MAX_VALUE / 3);
19 |     int low = 0;
20 |     for (int i = 0; i < 1000000; i++) {
21 |         if (random(n) < n/2) {
22 |             low++;
23 |         }
24 |     }
25 |     System.out.println(low);
26 | }
27 | ```
28 | 
29 | 이상적으로는 50만개가 나와야하지만 계속 실행해봐도 666,666개와 가까운 값을 얻습니다. 이는 random 메서드의 결함인데 지정한 범위 '바깥'수가 종종 튀어나올 수 있습니다. rnd.nextInt()가 반환한 값을 Math.abs를 이용해 음수가 아닌 정수로 매핑하기 때문입니다. 라이브러리를 제대로 익히지 않고 사용하기 때문에 나타난 문제입니다.</br>
30 | 자바 7부터는 Random대신 `ThreadLocalRandom`을 사용하는 게 좋습니다. Random보다 속도도 더 빠르고 고품질의 무작위 수를 생성하기 때문입니다. 한편 포크-조인 풀이나 병렬 스트림에서는 SplittableRandom을 사용합시다.
31 | </br>
32 | 라이브러리를 익히고 사용하면 다음과 같은 이점들도 추가로 있습니다. 노력을 하지 않아도 성능이 지속해서 개선 될 수 있습니다. 또한 기능이 점점 많아진다는 것입니다. 라이브러리에 부족한 부분이 있다면 논의된 후 다음 릴리즈에 해당 기능이 추가도곤 합니다. 마지막으로 여러분으 작성한 코드가 많은 사람에게 낯익은 콛,가 됩니다. 결국 유지 보수하기가 쉬워지고 가독성이 좋아집니다.
33 | </br>
34 | 
35 | 


--------------------------------------------------------------------------------
/chap09/Item60.md:
--------------------------------------------------------------------------------
 1 | # [Item 60] 정확한 답이 필요하다면 float와 double은 피하라.
 2 | 
 3 | float와 dobule은 과학과 공학 계산용으로 설계 되었습니다. 이진 부동소수점 연산에 쓰이며, 넓은 범위의 수를 빠르게 정밀한 '근사치'로 계산하도록 설계되었습니다. 따라서 정확한 계산 결과가 필요할 때는 사용하면 안 됩니다. 특 히 금용 관련 계산과 맞지 않습니다. 0.1 혹은 10의 음의 거듭 제곱수(10^-1, 10-^2)를 표현할 수 없기 때문입니다.</br>
 4 | 예를 들어 1.03달러에서 42센트를 사용하고 남은 돈을 계산한다고 가정해봅시다.
 5 | ``` java
 6 | System.out.println(1.03  - 0.42);
 7 | ```
 8 | 이 코드는 0.6100000000000001를 출력합니다. 원하는 결과가 나오지 않음을 알 수 있습니다.</br>
 9 | 다음 예제는 주머니에는 1달러가 있고 10,20 .. 1달러 짜리의 사탕이 있습니다. 10센트짜리부터 하나씩 얼마나 살 수 있고, 잔돈을 확인하는 어설픈 코드입니다.
10 | 
11 | ``` java
12 | double funds = 1.00;
13 | int itemsBought = 0;
14 | for (double price = 0.10; funds >= price; price += 0.10) {
15 |     funds -= price;
16 |     itemsBought++;
17 | }
18 | System.out.println(itemsBought + " items bought.");
19 | System.out.println("Change: $" + funds);  
20 | ```
21 | 실행 결과 3개를 구매했고, 잔돈은 0.3999999999999999 달러가 출력되는 걸 확인할 수 있습니다. 이러한 금융 계산 문제에는 `BigDecimal`, `int` 혹은 `long`을 사용해야 합니다.
22 | 
23 | 다음 코드는 BigDecimal로 교체한 코드입니다. 
24 | 
25 | ``` java
26 | final BigDecimal TEN_CENTS = new BigDecimal(".10");
27 | 
28 | int itemsBought = 0;
29 | BigDecimal funds = new BigDecimal("1.00"); 
30 | 
31 | for (BigDecimal price = TEN_CENTS;
32 |         funds.compareTo(price) >= 0;
33 |         price = price.add(TEN_CENTS)) {
34 |     funds = funds.subtract(price);
35 |     itemsBought++;
36 |     }
37 | System.out.println(itemsBought + " items bought.");
38 | System.out.println("Money left over: $" + funds);
39 | ```
40 | 4개를 구매했고 잔돈은 0이 나온 걸 확인할 수 있습니다. 하지만 Dedecimal에는 두 가지 단점이 존재합니다. 기본타입보다 쓰기 불편하고 훨씬 느립니다. Bigdecimal의 대안으로 int, long를 사용할 수도 있습니다. 그럴경우 소숫점 관리랑 값의 크기는 따로 관리해줘야합니다.


--------------------------------------------------------------------------------
/chap09/Item61.md:
--------------------------------------------------------------------------------
 1 | # [Item 61] 박싱된 기본 타입보다는 기본 타입을 사용하라.
 2 | 
 3 | 자바의 데이터 타입은 기본형과 참조형이 있습니다. 기본형에 대응하는 참조 타입이 하나씩 있으며 이를 박싱된 기본 타입이라 합니다. 기본 타입과 박싱된 기본 타입은 분명한 차이가 있으며 용도에 맞게 사용해야합니다.</br>
 4 | 박싱된 기본 타입은 값 뿐만 아니라 식별성이 더해졌습니다. 즉 값이 같아도 서로 다르게 식별될 수 있습니다. 그리고 박싱 타입은 **null**을 가질 수 있습니다. 추가로 기본 타입은 박싱 타입보다 메모리와 시간 측면에서 더 효율적입니다.</br>
 5 | 
 6 | ``` java
 7 | // 잘못 구현된 비교자
 8 | Comparator<Integer> naturalOrder = 
 9 |     (i, j) -> (i < j) ? -1 : (i == j ? 0 : 1);
10 | ```
11 | 컴파일 오류도 생기지 않고 잘 실행되지만 런타임에서 엉뚱한 결과가 발생할 수 있습니다. new Integer(10), new Integer(10) 똑같은 값이지만 0이 아닌 1을 출력합니다. 첫번째 (i < j)는 오토언박싱이 일어나서 정상적으로 작동합니다. 하지만 (i == j)에서는 참조를 비교하기 때문에 false가 나오게 됩니다. 실무에서는 이와 같이 기본 타입을 다루는 비교자가 필요하면 `Comparator.naturalOrder`를 사용합시다. 비교자를 직접 만들면 비교자 생성 메서드나 기본타입을 받는 정적 compare 메서드를 사용해야 합니다.</br>
12 | 이 문제를 해결하려면 지역변수 2개를 두어 각각 박싱된 Integer 매개변수의 값을 기본타입으로 저장한 다음, 비교를 수행해야 합니다.
13 | 
14 | ``` java
15 | // 문제를 수정한 비교자
16 | Comparator<Integer> naturalOrder = (iBoxed, jBoxed) -> {
17 |     int i = iBoxed, j = jBoxed;
18 |     reutrn i < j ? -1 : (i == j ? 0 : 1);
19 | };
20 | ```
21 | 다음은 시간에 대한 문제입니다.
22 | 
23 | ``` java
24 | Long sum = 0L;
25 | for(long i = 0; i <= Integer.MAX_VALUE; i++) {
26 |     sum += i;
27 | }
28 | System.out.println(sum);
29 | ```
30 | 박싱과 언박싱이 반복되면서 굉장히 성능이 저하되는 걸 확인할 수 있습니다.
31 | 
32 | 
33 | 
34 | 


--------------------------------------------------------------------------------
/chap09/Item62.md:
--------------------------------------------------------------------------------
 1 | # [Item 62] 다른 타입이 적절하다면 문자열 사용을 피하라.
 2 | 
 3 | 문자열은 다른 값 타입을 대신하기엔 적절하지 않습니다.
 4 | 
 5 | ``` java
 6 | // 흔한 타입을 문자열로 처리한 부적절한 예
 7 | String compoundKey = className + "#" + i.next();
 8 | ```
 9 | 두 요소를 구분해주는 #이 두 요소 중 하나에서 쓰였다면 혼란을 초래할 수 있습니다. 각 요소를 개별로 접근하려면 문자열을 파싱해야 해서 느리고, 귀찮고, 오류 가능성도 커집니다. 이럴 경우 전용 클래스를 새로 만드는 편이 낫습니다. 보통 private 정적 멤버 클래스로 선언합니다.</br>
10 | 
11 | ``` java
12 | public final class ThreadLocal<T> {
13 |     public ThreadLocal() {}
14 |     public void set(T value);
15 |     public T get();
16 | }
17 | ```
18 | 


--------------------------------------------------------------------------------
/chap09/Item63.md:
--------------------------------------------------------------------------------
 1 | # # [Item 63] 문자열 연결은 느리니 주의하라.
 2 | 
 3 | 문자열 연결 연산자로 문자열을 n개를 잇는 시간은 n^2에 비례합니다. 문자열은 immutable이라 두 문자열을 연결할 경우 양쪽의 내용을 모두 복사해야 하므로 성능 저하는 피할 수 없습니다.
 4 | 
 5 | ``` java
 6 | public String statement() {
 7 |     String result = "";
 8 |     for (int i = 0; i < numItems(); i++) {
 9 |         result += lineForItem(); // 문자열연결
10 |     }
11 |     return result;
12 | }
13 | ```
14 | `StringBuilder`를 활용하면 성능을 크게 개선할 수 있습니다.
15 | 
16 | ``` java
17 | // StringBuilder를 활용한 성능 개g선
18 | public String statement() {
19 |     StringBuilder sb = new SringBuilder(numItems() * LINE_WIDTH);
20 |     for (int i = 0; i < numItems(); i++) {
21 |         b.append(lineForItem(i));
22 |     }
23 |     return b.toString();
24 | }
25 | ```
26 | `


--------------------------------------------------------------------------------
/chap09/Item64.md:
--------------------------------------------------------------------------------
 1 | # [Item 64] 객체는 인터페이스를 사용해 참조하라.
 2 | 
 3 | ``` java
 4 | // 좋은 예
 5 | Set<Student> student = new HashSet<>();
 6 | ```
 7 | 
 8 | 
 9 | ``` java
10 | // 나쁜 예. 클래스 참조
11 | HashSet<Student> student = new HashSet<>();
12 | ```
13 | 인터페이스를 활용하면 유연함을 얻을 수 있습니다. 구현체를 교체하고 싶으면 구현 클래스만 바꾸면 됩니다.
14 | 
15 | ``` java
16 | // HashSet -> LinkedHashSet 교체
17 | Set<Student> student = new LinkedHashSet<>();
18 | ```
19 | 하지만 구현체를 바꿀 경우 주의할 점이 있습니다. 기존 구현체만의 특별한 기능을 제공하는 게 있다면, 바꿀 구현체에도 있는지 혹은 사이드 이펙트도 충분히 고려해야 합니다. 물론 적합한 인터페이스가 없을 경우는 당연히 클래스를 참조해야한다. 대표적으로 `String` 등이 있습니다.
20 | 


--------------------------------------------------------------------------------
/chap09/Item65.md:
--------------------------------------------------------------------------------
 1 | # [Item 65] 리플렉션보다는 인터페이스를 사용하라.
 2 | 
 3 | 리플렉션 기능을 활용하면 클래스에 접근 할 수 있습니다. Class객체가 주어지면 생성자, 메서드, 필드에 해당하는 Consturct, Method, Field 인스턴스를 가져올 수 있고 그 인스턴스들로는 그 클래스의 시그니처 등을 가져올 수 있습니다.
 4 | </br>
 5 | `Method.invoke`는 어떤 클래스의 어떤 객체가 가진 어떤 메서드라도 호출할 수 있게 해줍니다 물론 장점만있는 건 아닙니다. 단점은 다음과 같습니다.
 6 | 
 7 | - 컴파일타임 타입 검사가 주는 이점을 하나도 누릴 수 없다. 예외 검사도 마찬가지입니다. 리플렉션 기능으로 존재하지 않는 혹은 접근할 수 없는 메서드를 호출하려고하면 런타임 오류가 발생합니다.
 8 | - 리플렉션을 이용하면 코드가 지저분하고 장황해진다.
 9 | - 성능이 떨어진다. 리플렉션을 통한 메서드 호출은 일반 메서드 호출보다 느립니다.
10 | 
11 | 단점이 명백하게 존재하기 때문에 리플렉션을 써야하는 복잡한 애플리케이션도 리플렉션 사용을 점차 줄이고 있습니다. 컴파일 타임에 이용할 수 없는 클래스를 사용해야만 하는 프로그램은 비록 컴파일타임이라도 적절한 인터페이스나 상위 클래스를 이용할 수는 있을 것입니다. 이런 경우라면 리플렉션은 인스턴스 생성에만 쓰고, 이렇게 만든 인스턴스는 인터페이스나 상위 클래스로 참조해 사용합시다. 리플렉션은 컴파일타임에는 알 수 없는 클래스를 사용하는 프로그램을 작성한다면 리플렉션을 사용해야할 것입니다. 하지만 되도록 객체 생성에만 사용고 생성한 객체를 이용할 때는 적절한 인터페이스나 컴파일타임에 알 수 있는 상위 클래스로 형변환해서 사용해야 합니다.
12 | 


--------------------------------------------------------------------------------
/chap09/Item66.md:
--------------------------------------------------------------------------------
1 | # [Item 66] 네이티브 메서드는 신중히 사용하라.
2 | 
3 | 자바 네이티브 인터페이스는 자바 프로그램이 네이티브 메서드를 호출하는 기술입니다. 네이티브 메서드란 C나 C++같읕 네이비티브 프로그래밍 언어로 작성한 메서드를 말합니다. 네이티브 메서드의 주요 쓰임은 세 가지가 있습니다.
4 | 1. 레지스트리 같은 플랫폼 특화 기능을 사용한다.
5 | 2. 네이티브 코드로 작성된 기존 라이브러리를 사용한다.
6 | 3. 성능 개선을 목적으로 성능에 결정적인 영향을 주는 영역만 따로 네이티브 언어로 작성한다.
7 | 
8 | 
9 | 자바 9부터는 process API를 추가해 OS 프로세스에 접근하는 길을 열어주었고 자바에서 네이티브 메서드를 사용할 필요가 점점 줄어드는 추세입니다. 성능 개선을 목적으로 네이티브 메서드를 사용하는 건 권장하지 않습니다. JVM이 많이 발전한 덕에 속도가 굉장히 빨라졌기 떄문입니다. 또한 네이티브 언어가 안전하지 않으므로 네이티브 메서들 사용하는 애플리케이션도 메모리 훼손 오류로부터 안전하지 않습니다. 가비지 컬렉터가 네이티브 메모리는 자동 회수하지 못하고 추적 조차할 수 없습니다.


--------------------------------------------------------------------------------
/chap09/Item67.md:
--------------------------------------------------------------------------------
 1 | # [Item 67] 최적화는 신중히 하라.
 2 | 
 3 | 최적화는 좋은 결과보다 해로운 결과로 이어지기 쉽고, 자칫하면 빠르지도 않고 제대로 동작하지 않는 소프트웨어를 탄생시키는 것과 같습니다. 그러므로 최적화 할때는 득과실을 잘 생각해봐야 합니다.
 4 | 
 5 | ### 성능을 제한하는 설계를 피하라
 6 | 완성 후 변경하기가 가장 어려운 설계 요소는 바로 컴포넌트끼리 혹은 외부 시스템과의 소통 방식입니다. 대표적으로 API, 네트워크 프로토콜 등이 있습ㄴ디ㅏ. 이런 설계 요소들은 완성 후에는 변경하기 어려우며 동시에 시스템 성능을 심각하게 제한할 수 있습니다.
 7 | 
 8 | ### API 설계할 때 성능에 주는 영향을 고려하라.
 9 | public 타입을 가변으로 만들면 불필요한 방어적 복사를 유발할 수 있습니다. 또한 상속 방식으로 설계한 pulblic 클래스는 상위 클래스에 영원히 종석되며 성능 제약까지 물려받습니다.
10 | 
11 | 


--------------------------------------------------------------------------------
/chap09/Item68.md:
--------------------------------------------------------------------------------
1 | # [Item 68] 일반적으로 통용되는 명명 규칙을 따르라.
2 | 
3 | 자바이 명명 규칙은 크게 철자와 문법, 두 범주로 나뉘고 명명 규칙을 지켜야 좋은 프로그래밍이 될 수 있습니다. 대표적으로 메서드와 필드 내임의 첫 글자는 소문자를 사용합니다. 하지만 상수 필드의 경우 예외입니다. 상수는 모두 대무자를 이용하며 단어 사이는 _로 구분 합니다. ex)MAX_VALUE.. 상수 필드는 값이 static final 필드를 말합니다. 타입 매개변수 같은 경우 한 문자로 표현되며, 임의의 타입에는 T를, 컬렉션 원소의 타입은 E, 맵의 키와 값에는 K, V를, 예외는 X, 메서드의 반환 타입에는 R을 사용합니다. 그 외에 임의 타입 시퀀스에는 T, U, V 혹은 T1,T2,T3를 사용합니다.
4 | </br>
5 | 객체를 생성할 수 있는 클래스의 이름은 보통 명사나 명사구를 사용합니다. 객체를 만들 수 없는 클래스의 이름은 보통 복수형 명사로 짓습니다. 인터페이스 같은 경우 클래스랑 똑같이 짓거나 able 혹은 ible로 끝나는 형용사로 짓습니다.
6 | </br>
7 | 동작을 수행하는 메서드의 이름은 동사나 동사구로 짓습니다(append, drawImage). boolean을 반환하는 메서드는 is로 시작하고 명사구, 혹은 형용사로 기능하는 아무단어나 구로 끝나도록 짓습니다. 반환 타입이 해당 인스턴스의 속성을 반환하는 메서드는 보통 명사, 명사구, 혹은 get으로 시작하는 동사구로 짓습니다. get으로 시작하는 형태는 주로 자바빈즈 명세에 뿌리를 두고 있습니다.


--------------------------------------------------------------------------------
/chap10/Item69.md:
--------------------------------------------------------------------------------
 1 | # [Item 69] 예외는 진짜 예외 상황에서만 사용하라.
 2 | 
 3 | 예외는 반드시 예외 상황에서만 사용해야한다. 일반적인 제어 흐름용으로 사용하면 안 됩니다.
 4 | 
 5 | ``` java
 6 | try {
 7 |     int i = 0;
 8 |     while (true) {
 9 |         index[i++].doSomething();
10 |     }
11 | } catch (ArrayIndexOutOfBoundsException) {
12 |     ..
13 | }
14 | ```
15 | 코드가 장황하고 직관적이지 않습니다. 성능도 일반적인 제어 흐름보다 느립니다.


--------------------------------------------------------------------------------
/chap10/Item70.md:
--------------------------------------------------------------------------------
 1 | # [Item 70] 복구할 수 있는 상황에서는 검사 예외를, 프로그래밍 오류에는 런타임 예외를 시용하라.
 2 | 
 3 | 자바에서는 기본적으로 오류는 `checked exception`, `runtime exception`, `error` 이렇게 세 가지로 나눌 수 있습니다. 100% 확실한 건 아니지만 일반적으로 사용하는 상황은 다음과 같습니다.
 4 | </br>
 5 | </br>
 6 | 호출 하는 쪽에서 복구하리라 여거지는 상황에서는 검사 예외를 사용합시다. 이것이 검사 예외랑 비검사 예외를 구분하는 가장 기본적인 규칙입니다. catch로 잡아서 처리하거나 thorws로 예외를 호출한쪽으로 전파하고 호출했을 때 발생할 수 있는 있다는 걸 API 사용자에게 알리는 것입니다.
 7 | 
 8 | </br>
 9 | </br>
10 | 
11 | 반면 비검사 예외는 잡을 필요가 없습니다. 프로그램에서 비검사 예외를 던졌다는 것은 복구가 불가능 하거나 더 실행하면 득보다 실이 많다는 뜻입니다. 런타임 예외는 프로그래밍 오류를 나타낼떼 사용하는 게 좋습니다. 이러한 런타임 예외는 대부분 제약 조건에 부합하지 않을 때 사용되며 복구가 가능한지 불가능한지 명확히 구분되기 쉽지 않습니다. 만약 확신이 들지 않을 경우는 비검사 예외를 선택하는 게 좋을 것입니다.
12 | 
13 | </br>
14 | </br>
15 | 
16 | 에러는 보통 JVM 자원 부족 등 상황에서 사용합니다. 규약상 Error를 상속해 하위 클래스를 만드는 일은 좋지 않습니다. 비검사 예외를 구현할 때는 모두 RuntionException의 하위클래스 이어야 합니다.


--------------------------------------------------------------------------------
/chap10/Item71.md:
--------------------------------------------------------------------------------
1 | # [Item 71] 필요 없는 검사 예외 사용은 피하라.
2 | 
3 | 검사 예외를 필요한 곳에만 사용하면 프로그램의 안전성을 높여주지만, 과하게 사용하면 오히려 쓰기 불편한 API가 됩니다. API를 제대로 사용해도 발생할 수 있는 예외이거나, 프로그래머가 의미 잇는 조치를 취할 수 있는 경우 둘 중 어디에도 해당하지 않는다면 비검사 예외를 사용하는 것이 좋습니다.  


--------------------------------------------------------------------------------
/chap10/Item72.md:
--------------------------------------------------------------------------------
1 | # [Item 72] 표준 예외를 사용하라.
2 | 
3 | 자바에서는 기본적으로 다양한 예외를 제공해줍니다. 예외를 만들기 전 먼저 기존 라이브러리를 확인해보는 것이 좋습니다. 기존에 있는 라이브러리를 사용하면 API가 다른 사람이 익히기 쉬워집니다. 또한 예외 클래스가 적어질 수록 메모리 사용량도 줄고 클래스를 적재하는 시간도 적게 걸리기 때문입니다.
4 | </br>
5 | </br>
6 | 
7 | `Exception`, `RuntimeException`, `Throwable`, `Error`는 직적 재사용하지 않는 게 좋습니다. 다른 예외들의 상위 클래스이므로 즉 여러 예외를 포괄하기 때문에 안정적으로 테스트할 수 없습니다.


--------------------------------------------------------------------------------
/chap10/Item73.md:
--------------------------------------------------------------------------------
 1 | # [Item 73] 추상화 수준에 맞는 예외를 던져라.
 2 | 
 3 | 메서드가 저수준 예외를 처리하지 않고 바깥으로 전파해버릴 경우 예상치 못한 예외를 접하고 당황할 수가 있습니다. 이 문제를 피하려면 상위 계층에서 저수주 예외를 잡아 자신의 추상화 수준에 맞는 예외를 던져야 합니다. 이를 예외 번역이라 부릅니다.
 4 | 
 5 | ``` java
 6 | try {
 7 |     ...
 8 | } catch (LowLevelException e) {
 9 |     // 추상화 수준에 맞게 번역.
10 |     throw new HighLevelException(..);
11 | }
12 | ```
13 | `AbstractSequentialList`에서 수행하는 예외번역의 예시
14 | 
15 | ``` java
16 |     public E get(int index) {
17 |         try {
18 |             return listIterator(index).next();
19 |         } catch (NoSuchElementException exc) {
20 |             throw new IndexOutOfBoundsException("Index: "+index);
21 |         }
22 |     }
23 | ```
24 | 
25 | 예외 번역을 할 때, 저수준 예외가 디버깅에 도움이 된다면 예외 연쇄룰 사용하는게 좋습니다. 예외 연쇄란 근본 원인인 저수준 예외를 고수준 예외에 실어 보내는 방식입니다. 그러면 별도의 접근자 메서드(Throwable의 getCause 메서드)를 통해 필요하면 저수준 예외를 꺼내 볼 수 도 있습니다.
26 | 
27 | ``` java
28 | try {
29 |     ... // 저수준 추상화를 이용한다.
30 | 
31 | } catch (LowerLevelException cause) {
32 |     throw new HigherLevelException(cause);
33 | }
34 | ```
35 | 대부분 표준 예외는 예외 연쇄용 생성자를 갖추고 있습니다. 예외 연쇄는 문제의 원인을 프로그램에서 접근할 수 있게 해주며, 고수준 예외의 스택 추적 정보를 잘 통합해줍니다. 그렇다고 남용하지는 맙시다. 가능한 저수준 메서드가 반드시 성공하도록 하여 아래 계층에서 예외가 발생하지 않도록 하는 것이 베스트입니다.


--------------------------------------------------------------------------------
/chap10/Item74.md:
--------------------------------------------------------------------------------
1 | # [Item 74] 메서드가 던지는 모든 예외를 문서화하라.
2 | 
3 | 검사 예외는 항상 따로따로 선언하고, 각 예외가 발생하는 상황을 자바독의 @throws 태그를 사용하여 정확히 문서화를 합시다. 상위 클래스 하나로 선언하는 일은 삼가는 게 좋습니다. 어떤 예외를 호출하는지 명확하게 알 수 없고, 같은 맥락에서 다른 예외가 발생할 여지가 있을 경우 이러한 것까지 다 삼켜버릴 수 있기 때문입니다. 비검사 예외 같은 경우 메서드 선언에 throws를 넣는 건 권장하지 않습니다. 검사냐 비검사냐에 따라 API 사용자가 할 일이 달라지므로 이 둘은 확실히 구분해두는 것이 좋습니다.


--------------------------------------------------------------------------------
/chap10/Item75.md:
--------------------------------------------------------------------------------
1 | # [Item 75] 예외 상세 메시지에 실패 관련 정보를 담으라.
2 | 
3 | 스택 트레이스는 예외 객체의 toString 메서드를 호출해 얻는 문자열입니다. toString 메서드에 발생 원인에 대한 정보는 가능한 많을 수록 좋습니다. 물론 장황하지 않고 필요한 정보만 담는 것입니다. 가장 좋은 건 발생한 예외에 관여된 모든 매개변수와 필드의 값을 실패 메세지에 담는 것입니다. 물론 보안관 관련된 정보는 유의해서 다루어야 합니다.
4 | </br>
5 | </br>
6 | 
7 | ex) IndexOutOfBoundsException의 상세 메세지에는 범위의 최솟값, 최댓값, 범위를 벗어난 인덱스의 값을 담는 것입니다.


--------------------------------------------------------------------------------
/chap10/Item76.md:
--------------------------------------------------------------------------------
 1 | # [Item 76] 가능한 한 실패 원자적으로 만들라.
 2 | 
 3 | 여기서 말하는 실패 원자적이란 호출한 메서드가 실패하더라도 해당 객체는 호출 전 상태로 유지되는 것입니다. 가장 간단한 방법은 불변 객채로 설계하는 것입니다. 가변 객체일 경우 작업 수행 전에 유효성을 검사합는 것입니다.
 4 | 
 5 | ``` java
 6 | public Object pop() {
 7 |     if (size == 0) {
 8 |         throw new EmptyStachException();
 9 |     }
10 |     Object result = el[--size];
11 |     el[size] = null; // 참조 해제
12 |     return result;
13 | }
14 | ```
15 | 유효성 검사하는 부분이 없어도 ArrayOutOfBoundsException을 던지지만 이는 추상화 수준에 상황에 어울리지 않습니다.


--------------------------------------------------------------------------------
/chap10/Item77.md:
--------------------------------------------------------------------------------
 1 | # [Item 77] 예외를 무시하지 마라.
 2 | 
 3 | 발생할 수 있는 실수
 4 | ``` java
 5 | 
 6 | try {
 7 |     ...
 8 | } catch (IllegalArgumentException e){
 9 | }
10 | ```
11 | 초보 프로그래머가 할 수 있는 실수입니다. catch 블록에서 아무것도 하지 않으면 catch가 존재할 이유가 없어지는 것과 마찬가지입니다. 예외가 발생허더라도 계속 지나칠 수 있습니다. 이는 심각한 결함으로 이어질 수 있습니다. 만약 예외를 무시하기로 결정한 부분이라면 IllegalArgumentException ignored로 바꿔놓는 것이 좋습니다.


--------------------------------------------------------------------------------
/chap11/Item78.md:
--------------------------------------------------------------------------------
 1 | # [Item 78] 공유중인 가변 데이터는 동기화해 사용하라.
 2 | 
 3 | 동기화란 특정 메서드나 블럭에 한 쓰레드가 접근했을 때, 해당 객체에 락을 걸고 다른 쓰레드가 접근하지 못하도록 하는 것이다.
 4 | 
 5 | ``` java
 6 | public class StopThread {
 7 | 
 8 |   private static boolean stopRequested;
 9 | 
10 |   public static void main(String[] args) throws InterruptedException {
11 |     Thread backgroundThread = new Thread(() -> {
12 |       int i = 0;
13 |       while (!stopRequested)
14 |         i++;
15 |     });
16 |     backgroundThread.start();
17 | 
18 |     TimeUnit.SECONDS.sleep(1);
19 |     stopRequested = true;
20 |   }
21 | }
22 | 
23 | ```
24 | 메인 스레드가 1초 후 stopRequested를 true로 설정하고 반복문을 빠져나올 거락 생각할 수 있지만, 끝나지 않고 계속 실행됩니다.</br>
25 | 원인은 동기화에 있습니다. 동기화 하지 않으면 메인 스레드가 수정한 값을 백그라운드 스레드가 언제쯤에나 보게 될지 보증할 수 없습니다.
26 | </br>
27 | stopRequested 필드를 동기화해 접근하면 이 문제를 해결할 수 있습니다.
28 | 
29 | ``` java
30 | // 정상적으로 종료한다.
31 | public class StopThread {
32 | 
33 |   private static boolean stopRequested;
34 | 
35 |   private static synchronized void requestStop() {
36 |     stopRequested = true;
37 |   }
38 | 
39 |   private static synchronized boolean stopRequested() {
40 |     return stopRequested;
41 |   }
42 | 
43 |   public static void main(String[] args) throws InterruptedException {
44 |     Thread backgroundThread = new Thread(() -> {
45 |       int i = 0;
46 |       while (!stopRequested())
47 |         i++;
48 |     });
49 |     backgroundThread.start();
50 | 
51 |     TimeUnit.SECONDS.sleep(1);
52 |     requestStop();
53 |   }
54 | }
55 | ```
56 | 쓰기와 읽기 모두가 동기화 되지 않으면 동작을 보장하지 않습니다. 
57 | </br>
58 | </br>
59 | volatile으로 필드를 선언하면 동기화를 생략해도 되고, 속도가 더 빠릅니다. volatile 한정자는 배타적 수행과는 상관없자먼 항상 최근에 기록된 값을 읽게 됨을 보장합니다.
60 | 
61 | ``` java
62 | public class StopThread {
63 | 
64 |   private static volatile boolean stopRequested;
65 | 
66 |   public static void main(String[] args) throws InterruptedException {
67 |     Thread backgroundThread = new Thread(() -> {
68 |       int i = 0;
69 |       while (!stopRequested)
70 |         i++;
71 |     });
72 |     backgroundThread.start();
73 | 
74 |     TimeUnit.SECONDS.sleep(1);
75 |     stopRequested = true;
76 |   }
77 | }
78 | ```
79 | 
80 | 하지만 volatile를 사용할 때도 주의할 점이 있습니다.
81 | ``` java
82 | public static volatile int num = 0;
83 | 
84 | public static int gernerateNum() {
85 |     return num++;
86 | }
87 | ```
88 | num필드는 원자적으로 접근할 수 있고 어떤 값이든 허용한다. 문제는 ++연산자인데 numgernerateNum는 필드에 두 번 접근한다. 먼저 값을 읽고, 그 다음에 1증가한 값을 저장하는 것이다. 이 두 접근 사이에 다른 스레드가 들어와 값을 읽을 경우 첫번째 스레드와 똑같은 값을 돌려받게 되다. 프로그램이 잘못된 결과를 계사해내는 이런 오류를 safety failure라고 한다.
89 | </br>
90 | </br>
91 | 
92 | 이러한 문제점들에 벗어나느 가장 좋은 방법은 가변 데이터를 공유하지 않는 것이다. 한 스레드가 데이터를 다 수정한 후 다른 스레드에 공유할 때는 해당 객체에서 공유하는 부분만 동기화해도 된다. 그럼 그 객체는 다시 수정할 일이 생기기 전까지 다른 스레드들은 동기화 없이 자유롭게 값을 이어갈 수 있다. 이러한 객체를 effective immutable이라 하며, 다른 스레드에 이런 객체를 건내는 행위는 safe publication이라 한다. 
93 | </br>
94 | 객체를 안전하게 발행하는 방법은 많다. 클래스 초기화 과정에서 객체를 정적 필드, volatile 필드, final 필드, 혹은 보통릐 락을 통해 접근하는 필드에 저장해도 되고 동시성 컬렉션에 저장하는 방법도 있다.


--------------------------------------------------------------------------------
/chap11/Item79.md:
--------------------------------------------------------------------------------
1 | # [Itemm 79] 과도한 동기화는 피하라.
2 | 
3 | 과도한 동기화는 성능을 저하시키고 교차상태에 빠뜨릴 수 있다.
4 | </br>
5 | liveness, safety failures를 피하려면 동기화 메서드나 동기화 블록 안에서는 제어를 절대로 클라이언트에게 양보하면 안 된다. ex) 동기화된 영역 안에서 재정의할 수 있는 메서드 호출 x, 클라이언트가 념겨준 함수 객체 호출 x
6 | </br> 
7 | </br> 
8 | 과도한 동기화는 성능을을 저하 시킨다. 가변 클래스를 작성하거든 동기화를 전혀 하지 말고, 그 클래스를 동시에 사용해야 하는 클래스가 외부에서 알아서 동기화 하게 하던가, 동기화를 내부에서 수행해 스레드 안전한 클래스로 만들자. 단 클라이언트가 외부에서 객체 전체에 락을 거는 것보다 동시성을 월등히 개선할 수 있을 때만 후자를 택해라. java.util은 첫번째 방식을 택했고 java.util.concurrent는 두 번째 방식을 취했다.


--------------------------------------------------------------------------------
/chap11/Item80.md:
--------------------------------------------------------------------------------
 1 | # [Item 80] 스레드보다는 실행자, 태스크, 스트림을 애용하라.
 2 | 
 3 | `Excutor Framework`는 인터페이스 기반의 유연한 태스크 실행 기능을 담고 있다.
 4 | 
 5 | ``` java
 6 | ExecutorService exec = Executors.newSingleThreadExecutor();
 7 | exec.excute(runnable); // 이 실행자에게 task를 넘김
 8 | exec.shutdown(); // graceful하게 종료 (이 작업이 실패하면 VM 자체가 종료되지 않을 것)
 9 | ```
10 | 이 외에도 다양한 기능을 실행할 수 있다. 실행자 서비스를 사용하기에 까다로운 애플리케이션도 있는데, 가벼운 서버라면 Executors.newCachedThreadPool이 일반적으로 좋은 선택이지만 CachedThreadPool은 무거운 프로덕션 서버에는 좋지 못하다. </br>
11 | CachedThreadPool에서는 요청받은 태스크들이 큐에 쌓이지 않고 즉시 스레드에 위임돼 실행한다 가용한 스레드가 없다면 새로 하나를 생성한다, 서버가 무거울 경우 CPU 이용률이 
12 | 100%로 치닫고, 새로운 태스크가 도착하는 족족 또 다른 스레드를 생성해 상황을 악화시킨다.
13 | </br>
14 | </br>
15 | 따라서 무거운 프로덕션 서버에서는 Executors.newFixedThreadPool이나 완전히통재할 수 있는 ThreadPoolExecutor를 직접 사용하는 편이 좋다.
16 | 


--------------------------------------------------------------------------------
/chap11/Item81.md:
--------------------------------------------------------------------------------
 1 | # [Item 81] wait와 notify보다는 동시성 유틸리티를 애용하라.
 2 | 
 3 | wait와 notify는 올바르게 사용하기가 아주 까다로우니 고수준 동시성 유틸리티를 사용하라.
 4 | </br>
 5 | java.util.concurrent의 고수준 유틸리티는 세 범주로 나눌 수 있다.
 6 | 
 7 | - 실헹자 프레임워크
 8 | - 동시성 컬렉션
 9 | - 동기화 장치
10 | 
11 | 동시성 컬렉션은 높은 동시성에 도달하기 위해 동기화를 각자의 내부에서 구현한다. 따라서 컬렉션에서 동기성을 무력화하는 건 불가능하며 외부에서 락을 추가로 사용하면 속도가 느려진다.
12 | </br>
13 | 동시성을 무력화하지 못하므로 여러 메서드를 원자적으로 묶어 호출하는 건 불가능하다. 그레서 여러 기본 동작을 하나의 원자적 동작으로 묶는 '상태 의존적 수정' 메서드들이 추가되었다. 이 메서드들은 유용하여 자바 8에서는 일반 컬렉션 인터페이스에더 디폴트 메서드로 추가되었다.
14 | </br>
15 | </br>
16 | 
17 | 자주 쓰이는 동기화 장치는 `CountDownLatch`, `Semaphore`, `Phaser`가 있습니다.
18 | 
19 | ``` java
20 | // 동시에 실행 시간을 재는 간단한 프레임워크 (wait, notify만으로 구현하려면 난해해진다)
21 |   public static long time(Executor executor, int concurrency, Runnable action) throws InterruptedException {
22 |     CountDownLatch ready = new CountDownLatch(concurrency);
23 |     CountDownLatch start = new CountDownLatch(1);
24 |     CountDownLatch done = new CountDownLatch(concurrency);
25 | 
26 |     for (int i = 0; i < concurrency; i++) {
27 |       executor.execute(() -> {
28 |         // 타이머에 준비를 마쳤음을 알린다.
29 |         ready.countDown();
30 |         try {
31 |           // 모든 작업자 스레드가 준비될 때까지 기다린다.
32 |           start.await();
33 |           action.run();
34 |         } catch (InterruptedException e) {
35 |           Thread.currentThread().interrupt();
36 |         } finally {
37 |           // 타이머에게 작업을 마쳤음을 알린다.
38 |           done.countDown();
39 |         }
40 |       });
41 |     }
42 | 
43 |     ready.await(); // 모든 작업자가 준비될 때까지 기다린다.
44 |     long startNanos = System.nanoTime();
45 |     start.countDown(); // 작업자들을 깨운다.
46 |     done.await(); // 모든 작업자가 일을 끝마치기를 기다린다.
47 |     return System.nanoTime() - startNanos;
48 |   }
49 | ```
50 | time 메서드에 넘긴 실행자는 concurrency 매개변수로 지정한 동시성 수준만큼 스레드를 생성할 수 있어야 한다. 그렇지 못하면 이 메서드는 결코 끝나지 않을 것이고 이럴 상태를 스레드 기아 교착상태(thread starvation deadlock)라 한다.


--------------------------------------------------------------------------------
/chap11/Item82.md:
--------------------------------------------------------------------------------
 1 | # [Item 82] 스레드 안전성 수준을 문서화하라.
 2 | 
 3 | 일반적으로 스레드 안정성이 높은 순
 4 | - 불변: 외부 동기화가 필요없다. 대표적으로 String, Long, BigInteger
 5 | - 무조건적 스레드 안전: 이 클래스의 인스턴스는 수정될 수 있으나, 내부에서 충실히 동기화하여 별도의 외부 동기화 없이 사용해도 안전 대표적으로 ConcurrentHashMap
 6 | - 조건부 스레드 안전: 일부 메서드는 동시에 사용하려면 외부 동기화가 필요. Collections.synchronized 래퍼 메서드가 반환한 컬렉션이 여기 속함
 7 | - 스레드 비안전: 동시에 시용하려면 메서드 호출을 클라이언트가 선택한 외부 동기화 메커니즘으로 감싸야한다. ArrayList, HashMap 같은 기본 컬렉션.
 8 | - 스레드 적대적: 이 클래스는 모든 메서드 호출을 외부 동기화로 감싸더라도 멀티스레드 환경에서 안전하지 않다.
 9 | 
10 | 모든 클래스가 자신의 스레드 안전성 정보를 명확하게 문서화 해야한다. 애너테이션을 활용할 수도 있다. synchronized 한정자는 문서화랑 관련이 없다. 구현 이슈일 뿐 API에 속하지 않기 떄문이다.


--------------------------------------------------------------------------------
/chap11/Item83.md:
--------------------------------------------------------------------------------
 1 | # [Item 83] 지연 초기화는 신중히 사용하라.
 2 | 
 3 | 지연 초기화는 필드의 초기화 시점을 그 값이 처음 필요햔 시점까지 늦추는 것이다. 지연 초기화는 인스턴스 생성시 초기화 비용을 줄일 수 있지만, 지연 초기화하는 필드에 접근하는 비용은 커진다. 지연 초기화를 잘못사용하면 실제로 성능이 더 느려질 수도 있다.
 4 | </br>
 5 | </br>
 6 | 멀티 스레드 환경에서 지연 초기화를 하기에는 까다롭다. 지연 초기화하는 필드를 둘 이상 스레드가 공유한다면 동기화해야 한다. 일반적으로 일반적인 초기화가 지연 초기화보다 낫다.
 7 | 
 8 | ``` java
 9 | // 인스턴스 필드를 초기화하는 일반적인 방법
10 | private final FieldType field = computerFieldValue();
11 | ```
12 | 
13 | ``` java
14 | // 지연 초기화 - sychronized 방식
15 | private FieldType field;
16 | 
17 | private sychronized FieldType getField() {
18 |     if (field == null) {
19 |         field = computerFieldValue();
20 |     }
21 |     return field;
22 | }
23 | ```
24 | 
25 | ``` java
26 | // 정적 필드용 지연 초기화 홀더 클래스 관용구
27 | private static class FieldHolder {
28 |     static final FieldType field = computerFieldValue();
29 | }
30 | 
31 | private static FieldType getField() {
32 |     return FieldHolder.field();
33 | }
34 | ```
35 | getField가 호출되는 순간 FieldHolder.field가 처음 읽히면서 FieldHolder 클래스 초기화를 촉발한다. 일반적인 VM은 클래스를 초기화 할때만 필드 접근을 동기화할 것이다. 클래스 초기화가 끝난 후에는 VM이 동기화 코드를 제거하여, 그 다음부터는 아무런 검사나 동기화 없이 필드에 접근하게 된다.
36 | 
37 | </br></br>
38 | 성능 때문에 인스턴스 필드를 지연 초기화 한다면 이중검사 관용구를 사용하라. 한 번은 동기화 없이 검사하고 두 번째는 동기화하여 검사한다. 두 번째 검사에서 필드가 초기화되지 않았을 때만 초기화한다.
39 | 
40 | ``` java
41 |   private volatile FieldType fieldType;
42 | 
43 |   private FieldType getFieldType() {
44 |     FieldType result = fieldType;
45 |     if (result != null) { // 첫 번째 검사 (락 사용 x)
46 |       return result;
47 |     }
48 |     
49 |     synchronized (this) {
50 |       if (fieldType == null) { // 두 번째 검사 (락 사용)
51 |         fieldType = computerFieldValue();
52 |       }
53 |       return fieldType;
54 |     }
55 |   }
56 | ```
57 | 


--------------------------------------------------------------------------------
/chap11/Item84.md:
--------------------------------------------------------------------------------
1 | # [Item 84] 프로그램의 동작을 스레드 스케줄러에 기대지 말라.
2 | 
3 | 구체적인 스케줄링 정책은 운영체제 마다 다를 수 있다. 따라서 이 정책에 죄지우지 되면 안 된다. 실행 가능한 스레드의 평균적인 수를 프로세스 수보다 지나치게 많아지지 않도록 하는 것이 좋은 프로그래램이다. 그래야 스케줄러가 고민할 거리가 줄기 때문이다.


--------------------------------------------------------------------------------
/chap12/Item85.md:
--------------------------------------------------------------------------------
 1 | # [Item 85] 자바 직렬화의 대안을 찾으라.
 2 | 
 3 | 자바의 역직렬화에는 치명적인 단점이 있습니다. 신롸할 수 없는 스트림을 역직렬화하면 원격 코드 실행, 서비스 거부 등의 공격으로 이어질 수 있습니다.
 4 | 
 5 | </br>
 6 | </br>
 7 | 역직렬화 폭탄이란 서비스 거부 공격을 유발하는 스트림입니다.
 8 | 
 9 | ``` java
10 | static byte[] bomb() {
11 |     Set<Object> root = new HashSet<>();
12 |     Set<Object> s1 = root;
13 |     Set<Object> s2 = new HashSet<>();
14 |     for (int i = 0; i < 100; i++) {
15 |         Set<Object> t1 = new HashSet<>();
16 |         Set<Object> t2 = new HashSet<>();
17 |         t1.add("foo"); // t1을 t2와 다르게 만든다
18 |         s1.add(t1); s1.add(t2);
19 |         s2.add(t1); s2.add(t2);
20 |         s1 = t1;
21 |         s2 = t2;
22 |     }
23 |     return serialize(root); 
24 | }
25 | ```
26 | 이 코드는 끝날 기미가 보이지 않는다. HashSet 인스턴스를 역직렬화 하려면 원소들의 해시코드를 계산해야 하는데 위 코드에서는 hashCode 메서드를 2^100번 넘게 호출해야합니다.
27 | </br>
28 | 이러한 문제를 해결하는 가장 좋은 방법은 사용하지 않는 것입니다. 자바 직렬화보다 훨씬 간단하고 문제를 회피할 수 있는 방법으로 JSON과 프로토콜 버퍼가 대표적으로 있습니다.


--------------------------------------------------------------------------------
/chap12/Item86.md:
--------------------------------------------------------------------------------
 1 | # [Item 86] Serializable을 구현할지는 신중히 결정하라.
 2 | 
 3 | Serializable을 구현하면 릴리스 한 뒤에는 수정하기 어렵습니다. 직렬화 당시 내부 구현 방식에 묶이고, 캡슐화가 깨지는 위험이 있습니다. 직렬화된 클래스는 고유 식별 번호를 부여받는데, serialVersionUID를 명시하지 않으면 런타임에 SHA-1을 적용하여 자동으로 클래스 안에 생성해 넣는데, 클래스의 이름, 멤버 등이 포함됩니다. 그래서 나중에 이들 중 하나를 수정한다면 UID 값도 변하여 호환성이 깨져버립니다.
 4 | 
 5 | </br>
 6 | </br>
 7 | 그 다음 문제는 역직렬화는 숨은 생성자 입니다. 기본 역직렬화를 사용하면 불변식이 깨지고 허가되지 은 접근에 쉽게 노출됩니다.
 8 | </br>
 9 | </br>
10 | 세 번째 문제는 해당 클래스의 신버전을 릴리즈 할 때마다 직렬화 호환성을 검사해야하기 때문에 테스트해야 할 양이 직렬화 가능 클래스의 수와 릴리스 횟수에 비례하여 증가합니다.</br>
11 | 그래서 Serializable 구현 여부는 신중하게 결정해야합니다. 단 객체를 전송 / 저장할 때 자바 직렬화를 이용하는 프레임워크용으로 만든 클래스라면 선택의 여지가 없습니다.</br></br>
12 | 상속용으로 설계된 클래스나 인터페이스는 대부분 `Serializable`을 구현하면 안 됩니다. 그렇지 않으면 이 클래스를 확장할 때마다 커다란 부담감을 안겨주게됩니다. 예외적으로 `Throwable`은 서버가 RMI를 통해 클라이언트로 예외를 보내기 위해 Serializable을 구현했습니다.
13 | </br></br>
14 | 작성하는 클래스의 인스턴스 필드가 직렬화와 확장이 가능하다면 주의해야 할 것이 있습니다. finalize 메서드를 재정의하지 못하게 해야합니다. 그렇게 하지 않으면 finalizer 공격을 당할 수 있습니다. 마지막으로 인스턴스 필드 중 기본값으로 초기화하면 안 된다면 다음의 readObjectNoData 메서드를 반드시 추가해야합니다.
15 | 
16 | ``` java
17 | // 상태가 있고, 확장 가능하고, 직렬화 가능한 클래스용 readObjectNoData 메서드
18 | private void readObjectNoData() throws InvalidObjectException() {
19 |     throw new InvalidObjectException("스트림 데이터가 필요합니다");
20 | }
21 | ```
22 | 
23 | </br>
24 | Serializable를 구현하지 않을 때도 주의할 점이 있습니다. 상속용 클래스에서 직렬화를 지원하지 않고 하위 클래스에서 지원하는 상황에서 역직렬화를 하려면 상위 클래스는 매개변수 없는 생성자를 제공해야 하는데, 제공하지 않는다면 하위클래스에서 직렬화 프록시 패턴을 사용해야 합니다.</br>
25 | 내부 클래스는 이 필드들이 클래스 정의에 어떻게 추가되는지도 정의되지 않았기 때문에 직렬화를 구현하면 안 됩니다. 단 정적 멤버 클래스는 Serializable를 구현해도 됩니다.


--------------------------------------------------------------------------------
/chap12/Item87.md:
--------------------------------------------------------------------------------
  1 | # [Item 87] 커스텀 직렬화 형태를 고려해보라.
  2 | 
  3 | 이상적인 직렬화는 물리적인 모습과 독립된 논리적인 모습을 표현해야한다. 하지만 기본 직렬화 형태는 객체가 포함한 모든 데이터와 그 객체에서부터 시작해 접근할 수 있는 모든 객체를 담아낸다.
  4 | 
  5 | ``` java
  6 | public class Name implements Serializable {
  7 |     /*
  8 |      * 성. null이 아니어야 함.
  9 |      * @serial
 10 |      */
 11 | 
 12 |     private final String lastName;
 13 | 
 14 |     /*
 15 |      * 이름. null이 아니어야 함.
 16 |      * @serial
 17 |      */
 18 |     private final String firstName;
 19 | 
 20 |     /*
 21 |      * 이름. null이 아니어야 함.
 22 |      * @serial
 23 |      */
 24 |     private final String middleName;
 25 | 
 26 |     .. 
 27 | }
 28 | ```
 29 | 성명은 논리적으로 이름, 성, 중간이라는 3개의 문자열로 구성되며, 앞 코드의 인스턴스 필드들은 이 논리적 구성요소를 정확히 반영했음.
 30 | </br></br>
 31 | 
 32 | ``` java
 33 | // 기본 직렬화 형태에 적합하지 않은 클래스
 34 | public final class StringList implements Serializable {
 35 |   
 36 |   private int size = 0;
 37 |   private Entry head = null;
 38 |   
 39 |   private static class Entry implements Serializable {
 40 |     
 41 |     String data;
 42 |     Entry next;
 43 |     Entry previous;
 44 |   }
 45 |   ..
 46 | }
 47 | ```
 48 | ### 객체의 물리적 표환과 논리적 표현의 차이가 클 때 기본 직렬화를 사옹하면 발생하는 문제점
 49 | 1. 공개 API가 현재 내부 표현 방식에 영구히 묶인다. 위 코드에서는 StringList.Entry가 공개 API가 되어버린다. </br>
 50 | 다음 릴리스에서 내부 표현 방식을 변경하더라도 StringList 클래스는 연결 리스트로 펴현된 입력도 처리할 수 있어야한다. 
 51 | 
 52 | 2. 너무 많은 공간을 차지할 수 있다.위 코드에서 직렬화에 필요없는 연결리스트의 모든 엔트리와 연결 정보까지 저장했다.</br>이처럼 직렬화 형태가 너무 커져서 디스크에 저장하거나 네트워크에 전송하는 속도가 느려질 수 있다.
 53 | 3. 시간이 너무 많이 걸릴 수 있다. 직렬화 로직은 객체 그래프의 위상에 관한 정보가 없어서 그래프를 직접 순회해볼 수 밖에 없다.
 54 | 4. 스택 오버플로를 일으킬 수 있다. 기본 직렬화 과정은 객체 그래프를 재귀 순회하는데 크기가 크지 않는 객체 그래프에서도 오버플로를 일으킬 수 있다.
 55 | 
 56 | StringList를 합리적으로 직렬화려면 리스트가 포함한 문자열의 개수를 적은 뒤, 그 뒤로 문자열을 나열하는 수준이면 된다. 논리적인 구성만 담는 것이다.
 57 | 
 58 | ``` java
 59 | public final class StringList implements Serializable {
 60 | 
 61 |   private transient int size   = 0;
 62 |   private transient Entry head = null;
 63 |   
 64 |   // 더이상 직렬화 x
 65 |   private static class Entry {
 66 |     String data;
 67 |     Entry next;
 68 |     Entry previous;
 69 |   }
 70 |   // 지정한 문자열을 이 리스트에 추가
 71 |   public final void add(String s) { ... }
 72 | 
 73 |   /**
 74 |    * Serialize this {@code StringList} instance.
 75 |    *
 76 |    * @serialData 이 리스트의 크기(포함된 문자열의 개수) 를 기록한 후 ({@code int}), 이어서 모든 원소를(각각은 {@code String})순서대로 기
 77 |    */
 78 |   private void writeObject(ObjectOutputStream s) throws IOException {
 79 |     s.defaultWriteObject();
 80 |     s.writeInt(size);
 81 |     // 모든 원소를 올바른 순서로 기록한
 82 |     for (Entry e = head; e != null; e = e.next)
 83 |       s.writeObject(e.data);
 84 |   }
 85 |   private void readObject(ObjectInputStream s) throws IOException, ClassNotFoundException {
 86 |     s.defaultReadObject();
 87 |     int numElements = s.readInt();
 88 |     // 모든 원소를 읽어 이 리스트에 삽입한다
 89 |     for (int i = 0; i < numElements; i++)
 90 |       add((String) s.readObject());
 91 |   }
 92 |   ..
 93 | }
 94 | 
 95 | ```
 96 | 
 97 | `transient`이어도 defaultWriteObject, defaultReadObject를 호출해야 한다. 그래야 향후 릴리스에서 trasient가 아닌 인스턴스 필드가 추가되더라도 상호 호환이 되기 때문이다. 
 98 | </br>
 99 | 기본 직렬화 사용 여부와 상관없이 객체의 전체 상태를 읽는 메서드에 적용해야 하는 동기화 메커니즘을 직렬화에도 적용해야한다.
100 | 
101 | ``` java
102 | // 기본 직렬화를 사용하는 동기화된 클래스를 위한 writeObject 메서드
103 | private synchronized void writeObject(ObjectOutputStream s) 
104 |     throws IOException {
105 |     s.defaultWriteObject();
106 | }
107 | ```
108 | 
109 | writeObject 메서드 안에서 동기화하고 싶으면 클래스의 다른 부분에서 사용하는 락 순서를 똑같이 해야한다. 그렇지 않으면 교착상태에 빠질 수 있다.
110 | 
111 | </br>
112 | </br>
113 | 
114 | **어떤 직렬화 형태를 택하든 직렬화 가능 클래스 모두에 직렬버전 UID를 명시적으로 부여해주자**.</br>
115 | 이렇게 해야 잠재적인 호환성 문제가 사라진다. 성능도 조금 빨라지는데 명시하지 않을 경우 런타임에 UID 값을 생성하는 연산을 수행하기 때문이다. 구버전하고 호환성을 끊으려면 값을 변경해주면 된다.


--------------------------------------------------------------------------------
/chap12/Item88.md:
--------------------------------------------------------------------------------
  1 | # [Item 88] readObject 메서드는 방어적으로 작성하라.
  2 | 
  3 | ``` java
  4 | // 방어적 복사를 사용하는 불변 클ㄹ스
  5 | 
  6 | public final class Period {
  7 | 
  8 |     private final Date start;
  9 |     private final Date end;
 10 | 
 11 |     /**
 12 |     * @param start 시작 시간
 13 |     * @param end 종료 시각. 시작 시간보다 뒤어야 한다
 14 |     * @throws IllegalArgumentException 시작 시간이 종료 시간보다 늦을 때 발생한다
 15 |     * @throws NullPointerException start나 end가 null일시 발생
 16 |     */
 17 |     public Period(Date start, Date end) {
 18 |         this.start = new Date(start.getTime());
 19 |         this.end   = new Date(end.getTime());
 20 |             if (this.start.compareTo(this.end) > 0)
 21 |                 throw new IllegalArgumentException(tart + " after " + end);
 22 |     }
 23 | 
 24 |     public Date start () { return new Date(start.getTime()); }
 25 |     public Date end () { return new Date(end.getTime()); }
 26 |     public String toString() { return start + " - " + end; }
 27 |     ...
 28 |    }
 29 | ```
 30 | 
 31 | Period에 기본 직렬화 방법을 이용하면 주요한 불변식을 더는 보장하지 못하게 된다. readObject 메서드가 실질적으로 또 다른 public 생성자이기 때문이다. readObject는 매개변수로 바이트 스틤을 받는 생성자라고 할 수 있다. 불변식을 깨디를 의도로 임의 생성한 바이트 스트림을 건네면 정상적인 생성자로는 만들어낼 수 없는 객체를 생성해 낼 수 있기 떄문이다.
 32 | 
 33 | </br></br>
 34 |  이러한 문제를 해결하려면 Period의 readObject 메서드가 defaultReadObject를 호출한 다음 역직렬화된 객체가 유효한지 검사해야한다. 유효성 검사에 실패하면 InvalidObjectException을 던져서 역직렬화를 막을 수 있다.
 35 | 
 36 |  ``` java
 37 |  // 유효성 검사를 수행하는 readObject method - 아직 부족하다
 38 | private void readObject(ObjectInputStream s) throws IOException, ClassNotFoundException {
 39 |     s.defaultReadObject();
 40 | 
 41 |     // 불변식을 만족하는지 검사한다
 42 |     if (start.compareTo(end) > 0)
 43 |         throw new InvalidObjectException(start +" after "+ end);
 44 | }
 45 |  ```
 46 | 
 47 |  아직 맹점이 남아 있다. 정상 Period 인스턴스에서 시작된 바이트 스트림 끝에 private Date 필드로의 참조를 추가하면 가변 Period 인스턴스를 만들어낼 수 있다. ObjectInpuStream에서 Period 인스턴스를 읽은 후 스트림 끝에 추가된 악의적인 참조를 읽어 Period객체의 내부 정보를 얻을 수 있다.
 48 |  </br>
 49 |  이제 이 참조로 얻은 Date 인스턴스들은 수정할 수 있어서 Period는 더는 불변이 아니게 된다.
 50 | 
 51 |  ``` java
 52 |  // 가변 공격의 예
 53 |  public class MutablePeriod {
 54 | 
 55 |   public final Period period;
 56 |   public final Date start;
 57 |   public final Date end;
 58 | 
 59 |   public MutablePeriod() {
 60 |     try {
 61 |       ByteArrayOutputStream bos = new ByteArrayOutputStream();
 62 |       ObjectOutputStream out = new ObjectOutputStream(bos);
 63 | 
 64 |       // 유효한 Period 인스턴스를 직렬화한다.
 65 |       out.writeObject(new Period(new Date(), new Date()));
 66 | 
 67 |       /*
 68 |        * 악의적인 '이진 객체 참조', 즉 내부 Date 피드로의 참조를 추가한다.
 69 |        */
 70 |       byte[] ref = {0x71, 0, 0x7e, 0, 5}; // 참조 #5
 71 |       bos.write(ref); // 시작(start) 필드
 72 |       ref[4] = 4; // 참조 #4
 73 |       out.write(ref); // 종료(end) 필드
 74 |       
 75 |       // Period 역직렬화 후 Date 참조룰 '훔친다'
 76 |       ObjectInputStream in = new ObjectInputStream(new ByteArrayInputStream(bos.toByteArray()));
 77 |       period = (Period) in.readObject();
 78 |       start = (Date) in.readObject();
 79 |       end = (Date) in.readObject();
 80 |       
 81 |     } catch (ClassNotFoundException | IOException e) {
 82 |       throw new AssertionError(e);
 83 |     }
 84 |   }
 85 | }
 86 |  ```
 87 | 
 88 | 실제 공격이 이루어지는 코드
 89 | 
 90 | ``` java
 91 | public static void main(String[] args) {
 92 |     MutablePeriod mp = new MutablePeriod();
 93 |     Period p = mp.period;
 94 |     Date pEnd = mp.end;
 95 | 
 96 |     // 시간을 되돌리자
 97 |     pEnd.setYear(78);
 98 |     System.out.println(p);
 99 | 
100 |     // 60년대로 회귀
101 |     pEnd.setYear(69);
102 |     System.out.println(p);
103 | }
104 | ```
105 | 
106 | 심각한 보안 문제로 이어질 수 있다. 실제로 보안 문제를 String이 불변이라는 사실에 기댄 클래스들이 존재하기 많기 때문에 극단적인 예제라고 볼 수 없다. 객체를 역직렬화할 때는 클라이언트가 소유해서는 안 되는 객체 참조를 갖는 필드를 모두 반드시 방어적으로 복사해야한다. 띠리사 readObject에서는 불변 클래스 안의 모든 private 가변 요소를 방어적으로 복사해야한다.
107 | 
108 | ``` java
109 | // 방어적 복사와 유효성 검사를 수행하는 readObject 메서드
110 | private void readObject(ObjectInputStream s) throws IOException, ClassNotFoundException {
111 |     s.defaultReadObject();
112 | 
113 |     // 가변 요소를 방어적으로 복사한다.
114 |     start = new Date(start.getTime());
115 |     end   = new Date(end.getTime());
116 | 
117 |     // 불변식을 만족하는지 검사
118 |     if (start.compareTo(end) > 0)
119 |         throw new InvalidObjectException(start +" after "+ end);
120 | }
121 | ```
122 | final 필드는 방어적 복사가 불가능하다. 따라서 start와 end 필드에 final을 제거해야한다.
123 | 
124 | </br>
125 | </br>
126 | 
127 | 기본 readObject 메서드를 사용해도 괜찮을 때
128 | - transient 필드를 제외한 모든 필드의 값을 매개변수로 받아 유효성 검사 없이 필드에 대입하는 public 생성자를 추가해도 괜찮을 때
129 | 


--------------------------------------------------------------------------------
/chap12/Item89.md:
--------------------------------------------------------------------------------
  1 | # [Item 89] 인스턴스 수를 통제해야 한다면 readResolve 보단는 열거타입을 사용하라.
  2 | 
  3 | ``` java
  4 | // 싱글턴
  5 | public class Elvis {
  6 |     public static final Elvis INSTANCE = new Elvis(); 
  7 |     private Elvis() { ... }
  8 |        
  9 |     public void leaveTheBuilding() { ... }
 10 | }
 11 | ```
 12 | Serializable을 구현하는 순간 더이상 싱글턴이 아니다. 어떤 readObject를 사용하든 초기화될때 만들어진 인스턴스와는 별개인 인스턴스를 반환하게 된다.
 13 | </br>
 14 | </br>
 15 | readResolve 기능을 활용하면 readObject가 만들어낸 인스턴스를 다른 것으로 대체할 수 있다
 16 | 
 17 | ``` java
 18 | // 인스턴스 통제를 위한 readResolve - 개선의 여지가 있다.
 19 | private Object readResolve() {
 20 | 
 21 |     // wlsWK Elvis를 반환하고, 가짜 Elvis는 가비지 컬렉터에 맡긴다.
 22 |     return INSTANCE;
 23 | }
 24 | ```
 25 | 
 26 | readResolve를 인스턴스 통제 목적으로 사용한다면 객체 참조 타입 인스턴스 필드는 모두 transient로 선언해야 한다. 그렇지 않으면 역직렬화된 객체의 참조를 공격할 여지가 남는다.
 27 | 
 28 | </br>
 29 | </br>
 30 | 
 31 | 싱글턴이 transient가 아닌 참조 필드를 갖고 있다면, 그 필드의 내용은 readResolve 메서드가 실행되기 전에 역직렬화된다. 그렇다면 잘 조작된 스트림을 써서 참조 필드의 내용이 역직렬화 되는 시점에 그 역직렬화된 인스턴스의 참조를 훔쳐올 수 있다.
 32 | 
 33 | ``` java
 34 | // 잘못된 싱글턴 - transient가 아닌 참조 필드를 가지고 있다.
 35 | public class Elvis implements Serializable {
 36 |     public static final Elvis INSTANCE = new Elvis();
 37 |     private Elvis() { }
 38 | 
 39 |     private String[] favoriteSongs = { "Hound Dog", "Heartbreak Hotel" };
 40 | 
 41 |     public void printFavorites() {
 42 |         System.out.println(Arrays.toString(favoriteSongs));
 43 |     }
 44 |     private Object readResolve() {
 45 |            return INSTANCE;
 46 |     } 
 47 | }
 48 | ```
 49 | 
 50 | ``` java
 51 | // 도둑 클래스
 52 | 
 53 | public class ElvisStealer implements Serializable {
 54 |     static Elvis impersonator;
 55 |     private Elvis payload;
 56 | 
 57 |     private Object readResolve() {
 58 |         // resolve되기 전에 Elvis 인스턴스의 참조를 저장한ㄷ.
 59 |         impersonator = payload;
 60 | 
 61 |         // favoriteSongs 필드에 맞는 타입의 객체를 반환한다..
 62 |         return new String[] { "A Fool Such as I" };
 63 |        }
 64 | 
 65 |     private static final long serialVersionUID = 0;
 66 |    }
 67 | ```
 68 | 
 69 | ``` java
 70 | // 직렬화의 허점을 이용해 싱글턴 객체를 2개 생성한다
 71 | public class ElvisImpersonator {
 72 |      // 진짜 Elvis 인스턴스로는 만들어질 수 없는 바이트 스트림.
 73 |      private static final byte[] serializedForm = {
 74 |        (byte)0xac, (byte)0xed, 0x00, 0x05, 0x73, 0x72, 0x00, 0x05,
 75 |        0x45, 0x6c, 0x76, 0x69, 0x73, (byte)0x84, (byte)0xe6,
 76 |        (byte)0x93, 0x33, (byte)0xc3, (byte)0xf4, (byte)0x8b,
 77 |        0x32, 0x02, 0x00, 0x01, 0x4c, 0x00, 0x0d, 0x66, 0x61, 0x76,
 78 |        0x6f, 0x72, 0x69, 0x74, 0x65, 0x53, 0x6f, 0x6e, 0x67, 0x73,
 79 |        0x74, 0x00, 0x12, 0x4c, 0x6a, 0x61, 0x76, 0x61, 0x2f, 0x6c,
 80 |        0x61, 0x6e, 0x67, 0x2f, 0x4f, 0x62, 0x6a, 0x65, 0x63, 0x74,
 81 |        0x3b, 0x78, 0x70, 0x73, 0x72, 0x00, 0x0c, 0x45, 0x6c, 0x76,
 82 |        0x69, 0x73, 0x53, 0x74, 0x65, 0x61, 0x6c, 0x65, 0x72, 0x00,
 83 |        0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02, 0x00, 0x01,
 84 |        0x4c, 0x00, 0x07, 0x70, 0x61, 0x79, 0x6c, 0x6f, 0x61, 0x64,
 85 |        0x74, 0x00, 0x07, 0x4c, 0x45, 0x6c, 0x76, 0x69, 0x73, 0x3b,
 86 |        0x78, 0x70, 0x71, 0x00, 0x7e, 0x00, 0x02
 87 | };
 88 |      
 89 |     public static void main(String[] args) {
 90 |         // ElvisStealer.impersonator를 초기화 한 다음, 진짜 Elvis(Elvis.INSTANCE)를 반환
 91 |         Elvis elvis = (Elvis) deserialize(serializedForm); 
 92 |         Elvis impersonator = ElvisStealer.impersonator;
 93 | 
 94 |         elvis.printFavorites();
 95 |         impersonator.printFavorites();
 96 |      }
 97 | }
 98 | ```
 99 | 
100 | 출력 결과. 서로 다른 2개의 인스턴스를 생성할 수 있음을 증명했다.
101 | 
102 | >[Hound Dog, Heartbreak Hotel] </br>[A Fool Such as I]
103 | 
104 | ``` java
105 | // 열거 타임 싱글턴 - 전통적인 싱글턴보다 우수하다.
106 | public enum Elvis {
107 |     INSTANCE;
108 |     private String[] favoriteSongs = { "Hound Dog", "Heartbreak Hotel" };
109 | 
110 |     public void printFavorites() {
111 |     System.out.println(Arrays.toString(favoriteSongs));
112 |     } 
113 | }
114 | ```


--------------------------------------------------------------------------------
/chap12/Item90.md:
--------------------------------------------------------------------------------
 1 | # [Item 90] 직렬화된 인스턴스 대신 직렬화 프록시 사용을 검토하라.
 2 | 
 3 | 직렬화 프록시 패턴을 이용하면 앞서 애기했던 단점들을 줄일 수 있다.먼저 바깥 클래스의 논리적인 상태를 표현하는 중첩 클래스를 private static으로 생성한다. 이 중첩 클래스가 바깥 클래스의 직렬화 프록시다. 이 클래스는 단순히 인스로 넘어온 인스턴스의 데이터만 복사하고 바깥 클래스와 모두 Serializable을 구현해야한다.
 4 | 
 5 | </br>
 6 | </br>
 7 | 
 8 | ``` java
 9 | // Period 클래스용 직렬화 프록시
10 | private static class SerializationProxy implements Serializable { 
11 |     private final Date start;
12 |     private final Date end;
13 |     
14 |     SerializationProxy(Period p) {
15 |         this.start = p.start;
16 |         this.end = p.end;
17 |     }
18 |     private static final long serialVersionUID = 234098243823485285L; // do (Item 87)
19 | }
20 | ```
21 | 
22 | 다음은 바깥 클래스에 다음의 writeReplace 메서드를 추가한다. 직렬화 프록시를 사용하는 모든 클래스에서 그대로 사용하면 된다.
23 | 
24 | ``` java
25 | // 직려롸 프록시 패턴용 writeReplace 메서드
26 | private Object writeReplace() {
27 |     return new SerializationProxy(this);
28 | }
29 | ```
30 | 이 메서드는 직렬화가 이뤄지기 전에 바깥 클래스의 인스턴스를 직렬화 프록시로 변환해준다. writeReplace 결코 바깥 클래스의 직렬화된 인스턴스를 생성해낼 수 없다.
31 | </br>
32 | 
33 | ``` java
34 | // readObject를 바깥 클래스에 추가. ( 불변 훼손 공격 방어)
35 | private void readObject(ObjectInputStream stream) throws InvalidObjectException {
36 |     throw new InvalidObjectException("Proxy required");
37 | }
38 | ```
39 | 
40 | 마지막으로 바깥 클래스와 논리적으로 동일한 인스턴스를 반환하는 readResolve 메서드를 SerializationProxy 클래스에 추가한다. 이 메서드는 역직렬화 시에 직렬화 시스템이 직렬화 프록시를 다시 바깥 클래스의 인스턴스로 변환하게 해준다.
41 | 
42 | </br>
43 | </br>
44 | readObject 메서드는 공개된 API만을 사용해 바깥 클래스의 인스턴서를 생성하는데 장점은 다음과 같다.
45 | </br>
46 | - 직렬화는 생성자를 이용하지 않고도 인스턴스를 생성하는 기능을 제공하는데, 이 패턴은 직려화의 이런 특성을 상당 부분 제거한다. (인스턴스를 만들 때와 똑같은 생성자 등을 사용해 역직렬화된 인스턴스를 생성함)
47 | 
48 | 따라서 불변식을 만족하는 검사를 하지 않아도 된다.
49 | 
50 | ``` java
51 | // Period.SerializationProxy용 readObject메서드
52 |    private Object readResolve() {
53 |        return new Period(start, end);  // public constructor 사용.
54 | }
55 | 
56 | ```
57 | 프록시 수준에서 내부 필드 탈취 공격을 차단해준다. 또한 필드에 final을 선언해도 돼서 Period 클래스를 진정한 불변으로 만들 수 있다. 또한 직렬화 프록시 패턴은 역직렬화한 인스턴스와 원래의 직렬화된 인스턴스의 클래스가 달라도 정상 작동한다.
58 | </br>
59 | </br>
60 | 
61 | 프록시 패턴의 한계
62 | - 클라이언트가 멋대로 확장할 수 있는 클래스에는 적용할 수 없다.
63 | - 객체 그래프에서 순환이 있는 클래스에도 적용할 수 없다.
64 | - 성능이 느리다. 
65 | 
66 | 
67 | 


--------------------------------------------------------------------------------