docs: Update to item14

하은혜/item1.md → 하은혜/Chap2-객체의_생성과_파괴/item1.md

@@ -379,7 +379,7 @@
    ```
 
   - 자바독 생성 시, 생성자는 생성자의 영역이 따로 존재하여 인스턴스를 어떻게 생성할 수 있는 지를 한 눈에 볼 수 있는 반면 정적 팩토리 매서드는 메서드 부분에 들어가 있어 해당 클래스에서 제공하는 메서드가 많아지는 경우 인스턴스를 생성해주는 용도의 메서드를 찾기가 어렵게 될수도 있다.
-    ![image.png](image/javadoc_settings.png)
+    ![image.png](../image/javadoc_settings.png)
 
   - 이에 책에서는 네이밍 패턴을 사용하여 알아보기 쉽게 하는 것과 문서화를 제안하고 있다. 문서화의 예시는 아래와 같다.
      ```java
@@ -405,4 +405,4 @@
 
      }
      ```
-    ![image.png](image/javadoc_settings2.png)
+    ![image.png](../image/javadoc_settings2.png)

하은혜/Chap2-객체의_생성과_파괴/item9.md

@@ -0,0 +1,87 @@
+# ITEM 9. try-finally 보다 try-with-resouces를 사용하라
+
+> **꼭 회수해야하는 자원을 다룰 때는 try-finally 말고, try-with-resources를 사용하자. 예외는 없다. 코드는 더 짧고 분명해지고, 만들어지는 예외 정보도 훨씬 유용하다. try-finally로 작성하면 실용적이지 못할 만큼 코드가 지저분해지는 경우라도, try-with-resources로는 정확하고 쉽게 자원을 회수할 수 있다.**
+
+## Try-Finally
+
+- try-finally는 더이상 최선의 방법이 아니다.(자바7부터)
+- 이전에는 try-finally 구문을 이용해서 자원을 회수하는 경우가 많았는데, 회수해야 할 자원이 많아지면 코드가 복잡해지면서 가독성이 나빠지고 자원을 제대로 회수하지 못할 수 있다.
+
+```java
+// 코드 9-1 : 간단한 try-finally 예제
+// 문제 없이 정상동작한다.
+static String firstLineOfFile(String path) throws IOException {
+    BufferedReader br = new BufferedReader(new FileReader(path));
+    try {
+        return br.readLine();
+    }finally {
+        br.close();
+    }
+}
+```
+
+```java
+// 코드 9-2 : 회수해야할 자원이 둘 이상인 try-finally 예제
+// 코드가 복잡해져 가독성이 나빠진다.
+public class Copy {
+
+    private static final int BUFFER_SIZE = 8 * 1024;
+
+    static void copy(String src, String dst) throws IOException {
+
+        FileInputStream in = new FileInputStream(src);
+        try {
+            FileOutputStream out = new FileOutputStream(dst);
+            try {
+                byte[] buf = new byte[BUFFER_SIZE];
+                int n;
+                while ((n = in.read(buf)) >= 0)
+                    out.write(buf, 0, n);
+            }finally {
+                out.close();
+            }
+        }finally {
+            in.close();
+        }
+
+    }
+
+}
+```
+
+```java
+// 단일 try-finally로 구성한 예제
+// 오류 발생 시 자원이 제대로 회수되지 않을 수 있다.
+static void copyLeak(String src, String dst) throws IOException {
+    FileInputStream in = new FileInputStream(src);
+    FileOutputStream out = new FileOutputStream(dst);
+    try {
+        byte[] buf = new byte[BUFFER_SIZE];
+        int n;
+        while ((n = in.read(buf)) >= 0)
+            out.write(buf, 0, n);
+    }finally {
+        // 여기서 에러 발생하면
+        out.close();
+        // 이건 실행 안됨.
+        in.close();
+    }
+}
+```
+
+## Try-With-Resources
+
+- try-with-resources를 사용하면 코드가 더 짧고 분명하다.
+
+```java
+static String firstLineOfFileWithResources(String path) throws IOException {
+    try(BufferedReader br = new BadBufferReader(new FileReader(path));) {
+        return br.readLine();
+    }
+}
+```
+
+- 만들어지는 예외 정보도 훨씬 유용하다.
+    - try-finally로 작성할 경우, 첫번째 발생한 예외는 보여주지 않고, 마지막 예외만 보여지는 형태가 된다
+    - 하지만 실제로는 첫번째 발생한 예외가 후속 예외를 발생시키는 경우가 많아 어떤 지점에서 예외가 발생되었는지를 명확하게 파악하기 위해서는 첫번째 발생한 예외가 중요하다.
+    - try-with-resources 모든 예외를 보여준다.

하은혜/Chap3-모든_객체의_공통_메서드/item10.md

@@ -0,0 +1,54 @@
+# ITEM 10. equals는 일반 규약을 지켜 재정의하라
+
+> **꼭 필요한 경우가 아니면 equals를 재정의하지 말자. 많은 경우에 Object의 equals가 여러분이 원하는 비교를 정확히 수행해준다. 재정의해야 할 때는 그 클래스의 핵심 필드 모두를 빠짐없이, 다섯 가지 규약을 확실히 지켜가며 비교해야 한다.**
+
+## equals를 재정의 하지 않는 것이 최선
+
+- 다음의 경우에 해당한다면 equals를 재정의 할 필요가 없다.
+- 각 인스턴스가 본질적으로 고유하다.
+- 인스턴스의 ‘논리적 동치성’을 검사할 필요가 없다.
+  - String과 같은 자료형
+- 상위 클래스에서 재정의한 equls가 하위 클래스에도 적절하다.
+  - list나 set의 경우, list는 abstract list에 set은 abstract set에 구현되어 있다.
+- 클래스가 private이거나 package-private이고 equals 메서드를 호출할 일이 없다.
+  - public클래스는 해당 클래스를 이용해 equals 메서드가 호출될 일이 있을 지 아닐 지 알 수가 없기 때문에 equals 메서드를 호출하지 않을 것이라 장담할 수 없다. 하지만 제한되어 있는 클래스인 경우, equals를 안쓸꺼라는 것을 어느정도 보장할 수 있다.
+- equals를 재정의 해야 하는 경우
+  - 객체 식별성(object identity, 두 객체가 물리적으로 같은가)이 아닌 “논리적 동치성”을 확인해야 하는데, 상위 클래스의 equals가 논리적 동치성을 비교하도록 재정의 되지 않았을 때 (주로 값 클래스)
+
+## equals 규약
+
+- 반사성 : A.equals(A) == true
+- 대칭성 : A.equals(B) == B.equals(A)
+  - CaseInsensitiveString
+  - Date와 Timestamp는 이 대칭성 규약이 깨져있다.(둘은 상속관계)
+  - 안정적으로 대칭성이 유지된 코드를 작성하고 싶다면 상속관계를 사용하지 않고 내부에서 선언하여 각각의 필드가 같은지 확인하는 식으로 코드를 작성하면 된다.
+- 추이성 : A.equals(B) && B.equal(C), A.equals(C)
+  - Point, ColorPoint(inherit), CounterPointer, ColorPoint(comp)
+- 일관성 : A.equals(B) == A.equals(B)
+  - 일관성을 지키고 싶다면 너무 복잡하게 구성하면 안된다.
+  - 복잡하게 되어있는 예시로는 URL에 있는 equals 이다. URL에 있는 equals는 그 URL이 가르키는 ip까지를 확인하기 때문에 일관성이 깨진다.
+- null-아님 : A.equals(null) == false
+
+## equals 구현 방법
+
+- == 연산자를 사용해 자기 자신의 참조인지 확인한다.
+- instanceof 연산자로 올바른 타입인지 확인한다.
+- 입력된 값을 올바른 타입으로 형변환 한다.
+- 입력 객체와 자기 자신의 대응되는 핵심 필드가 일치하는지 확인한다.
+- 추가.
+  - float이나 double과 같은 부동소수점의 영향을 받는 자료형들은 equals가 아닌 해당 자료형에서 제공하는 compare()함수를 이용하여 비교하라.
+  - 레퍼런스 타입의 경우는 레퍼런스 타입이 가지고 있는 equals를 사용하여 비교하면 된다.
+  - null을 허용하고 싶다면 Objecs.equals()를 사용하면 된다.
+
+- 구글의 AutoValue 또는 Lombok을 사용한다.
+- IDE의 코드 생성 기능을 사용한다.
+  - 코드가 약간 지저분해질 수 있고, 필드가 늘어날 때마다 다시 만들어줘야한다는 단점이 있다.
+- Record 기능
+  - 자바14버전부터 들어가 있고, 자바 버전의 15버전부터 본격적으로 사용할 수 있다.
+  - 자바 17버전이상을 사용한다면 고려할 수 있는 방법.
+
+- 주의사항
+  - equals를 재정의 할 때 hashCode도 반드시 재정의하자(아이템11)
+  - 너무 복잡하게 해결하지 말자.
+  - Object가 아닌 타입의 매개변수를 받는 equals 메서드는 선언하지 말자.
+  - 논리적인 동치성을 보장하려면 반드시 equals 메소드를 orverride 해야한다.

하은혜/Chap3-모든_객체의_공통_메서드/item11.md

@@ -0,0 +1,39 @@
+# ITEM 11. equals를 재정의하려거든 hashCode도 재정의하라
+
+> **equals를 재정의할 때는 hashCode도 반드시 재정의해야 한다. 그렇지 않으면 프로그램이 제대로 동작하지 않을 것이다. 재정의한 hashCode는 Object의 API문서에 기술된 일반 규약을 따라야 하며, 서로 다른 인스턴스라면 되도록 해시코드도 서로 다르게 구현해야 한다. 이렇게 구현하기가 어렵지는 않지만 조금 따분한 일이긴 하다. 하지만 걱정마시라. 아이템 10에서 이야기한 AutoValue 프레임워크를 사용하면 멋진 equals와 hashCode를 자동으로 만들어준다. IDE들도 이런 기능을 일부 제공한다.**
+
+## hashCode 규약
+
+- equals 비교에 사용하는 정보가 변경되지 않았다면 hashCode는 매번 같은 값을 리턴해야 한다. ( 변경되거나, 애플리케이션을 다시 실행했다면 달라질 수 있다. )
+- **두 객체에 대한 equals가 같다면, hashCode의 값도 같아야 한다.**
+- 두 객체에 대한 equals가 다르더라도, hashCode의 값은 같을 수 있지만 해시 테이블 **성능을 고려해 다른 값을 리턴하는 것이 좋다.**
+  - 항상 같은 hashCode를 리턴하게 되면 성능이 O(1) 에서 O(n) 으로 떨어지게 된다.
+
+## hashCode 구현 방법
+
+```java
+@Override public int hashCode() {
+  int result = Short.hashCode(areaCode);  // 1
+  result = 31 * result + Short.hashCode(prefix);  // 2
+  result = 31 * result + Short.hashCode(lineNum);  // 3
+  return result;
+}
+
+// areacode, prefix, lineNum은 PhoneNumber(선언한 클래스)클래스의 변수다.
+```
+
+1. 핵심 필드 하나의 값의 해쉬값을 계산해서 result 값을 초기화 한다.
+2. 기본 타입은 Type.hashCode
+   참조 타입은 해당 필드의 hashCode
+   배열은 모든 원소를 재귀적으로 위의 로직을 적용하거나, Arrays.hashCode
+   result = 31 * result + 해당 필드의 hashCode 계산값
+3. result를 리턴한다.
+
+- 31인 이유
+  - 홀수를 사용해야한다. (짝수를 사용하면 비트연산이 발생하여 값이 왼쪽으로 밀리면서 날아갈수 있다.)
+  - 해시 충돌이 가장 적게 나는 숫자이다.
+
+## 기타
+
+- 그냥 자바의 Objects.hash()를 써라.
+- equals와 hashCode를 구현하면 해당 구현에 대한 테스트도 해야한다. 하지만 lombok을 사용하면 해당 부분은 테스트 하지 않아도 된다.

하은혜/Chap3-모든_객체의_공통_메서드/item12.md

@@ -0,0 +1,11 @@
+# ITEM 12. toString을 항상 재정의하라
+
+> **모든 구체 클래스에서 Object의 toString을 재정의하자. 상위 클래스에서 이미 알맞게 재정의한 경우는 예외다. toString을 재정의한 클래스는 사용하기도 즐겁고 그 클래스를 사용한 시스템을 디버깅하기 쉽게 해준다. toString은 해당 객체에 관한 명확하고 유용한 정보를 읽기 좋은 형태로 반환해야 한다.**
+
+- toString은 간결하면서 사람이 읽기 쉬운 형태의 유익한 정보를 반환해야 한다.
+- Object의 toString은 클래스이름@16진수로 표시한 해시 코드
+- 객체가 가진 모든 정보를 보여주는 것이 좋다.(강사님은 동의하지 않음)
+- 값 클래스라면 포맷을 문서에 명시하는 것이 좋으며 해당 포맷으로 객체를 생성할 수 있는 정적 팩터리나 생성자를 제공하는 것이 좋다.
+- toString이 반환한 값에 포함된 정보를 얻어올 수 있는 API를 제공하는 것이 좋다.
+- 경우에 따라 AutoValue, 롬복 또는 IDE를 사용하지 않는게 적절할 수 있다.
+    - 전화번호를 쪼개서 각 변수로 저장하는 클래스 같은 경우 한 줄, 혹은 포맷대로 나오는 것이 적절할 수 있다.

하은혜/Chap3-모든_객체의_공통_메서드/item13.md

@@ -0,0 +1,32 @@
+# ITEM 13. clone 재정의는 주의해서 진행하라
+
+> **Cloneable이 몰고 온 모든 문제를 되짚어봤을 때, 새로운 인터페이스를 만들 때는 절때 Cloneable을 확장해서는 안 되며, 새로운 클래스도 이를 구현해서는 안 된다. final 클래스라면 Cloneable을 구현해도 위험이 크지 않지만, 성능 최적화 관점에서 검토한 후 별다른 문제가 없을 때만 드물게 허용해야한다. (아이템 67). 기본 원칙은 ‘복제 기능은 생성자와 팩터리를 이용하는 게 최고’라는 것이다. 단, 배열만은 clone 메서드 방식이 가장 깔끔한, 이 규칙의 합당한 예외라 할 수 있다.**
+
+## 애매모호한 clone 규약
+
+- clone 규약
+    - x.clone() != x  `반드시 true`
+    - x.clone().getClass == x.getClass() `반드시 true`
+    - x.clone().equals(x) `true가 아닐 수도 있다.`
+- 불변 객체라면 다음으로 충분하다.
+    - Cloneable 인터페이스를 구현하고
+    - clone 메서드를 재정의한다. 이때 super.clone()을 사용해야 한다.
+
+## hashCode 구현 방법
+
+- 접근 제한자는 public, 반환 타입은 자신의 클래스로 변경한다.
+- super.clone을 호출한 뒤 필요한 필드를 적절히 수정한다.
+    - 배열을 복제할 때는 배열의 clone 메서드를 사용하라.
+    - 경우에 따라 final을 사용할 수 없을지도 모른다.
+    - 필요한 경우 deep copy를 해야한다.
+    - super.clone으로 객체를 만든 뒤, 고수준 메서드를 호출하는 방법도 있다.
+    - 오버라이딩 할 수 있는 메서드는 참조하지 않도록 조심해야 한다.
+    - 상속용 클래스는 Cloneable을 구현하지 않는 것이 좋다.
+    - Cloneable을 구현한 스레드 안전 클래스를 작성할 때는 동기화를 해야 한다.
+
+## 기타
+
+- “복사 생성자” 또는 변환 생성자, “복사 팩터리” 또는 변환 팩터리
+- 생성자를 쓰지 않으며, 모호한 규약, 불필요한 검사 예외, final 용법 방해 등에서 벗어날 수 있다.
+- 또 다른 큰 장점 중 하나로 인터페이스 타입의 인스턴스를 인수로 받을 수 있다.
+    - 클라이언트가 복제본의 타입을 결정할 수 있다.