[3주차] 이예림_Item 11,23

3장_모든_객체의_공통_메서드/아이템 12/toString은_항상_재정의하라.md

@@ -0,0 +1,67 @@
+## item 12
+
+### toString을 항상 재정의하라
+
+---
+
+### 🙋‍♀️ 왜 재정의하는 게 좋은가요?
+
+기본적인 `Object`의 `toString` 메서드를 사용한다면, 우리가 원하는 대로 문자열을 보통 반환하지 않는 다는 것을 알 수 있습니다.
+`PhoneNumber@abdbd` 처럼 `클래스_이름@16진수로_표시한_해시코드`를 반환할 뿐입니다. 
+
+그래서 우리는 `toString` 일반 규약에 따라 `간결하면서 사람이 읽기 쉬운 형태의 유익한 정보`를 반환해줘야 합니다.
+또한 이는 `모든 하위 클래스에서 이 메서드를 재정의하라` 라고 표현될만큼 매우 강조되고 있습니다.
+
+결국 재정의를 하게 되면, 해당 클래스를 사용할 때`즐겁고, 디버깅하기 쉽`습니다.
+
+#### 예시 1) 오류 메세지 로깅
+우리가 작성한 객체를 참조하는 컴포넌트가 오류 메세지를 로깅할 때 `toString`은 자동으로 호출될 수 있습니다.
+이때 보다 쉽게 파악하기 위해 `toString`을 정의해둔다면 `보다 의미있는 메세지를 얻어갈 것`이기에 재정의하는 게 좋습니다.
+
+대부분 프로그래머들은 진단 메시지를 
+```java
+System.out.println(phoneNumber + "에 연결할 수 없습니다.");
+```
+해당 방식으로 작성하게 됩니다. 재정의를 하지 않았다면 의미없는 메세지를 보게 되는 것입니다.
+
+#### 예시 2) 해당 객체를 포함하는 상황에서 출력을 진행
+이 객체를 포함하는 상황(ex `map 객체`)에 출력을 할 때 보다 의미있게 쓰이게 됩니다.
+`{Jenny=PhoneNumber@abdbd}`가 아닌 `{Jenny=707-867-5309}` 라는 의미있는 정보를 받게 될테니 말입니다.
+
+---
+
+### 🙋‍♀️ 그렇다면 어떻게 toString을 재정의해야 하나요?
+
+#### 1) 객체가 가진 주요 정보 모두를 반환하는 게 좋습니다.
+#### 2) `객체가 거대`하거나 `객체의 상태를 문자열로 표현하는 게 적합하지 않`다면 요약 정보를 담아서 합니다.
+#### 3) 반환값을 문서화할지 정합니다.
+
+---
+
+### 🙋‍♀️ 문서화할지 어떻게 정하나요?
+
+#### 1) 문서화의 장점
+표준적이고, 명확하고, 사람이 읽을 수 있게 됩니다. 
+그렇기에 `그대로 입출력에 사용`하거나 `데이터 객체로 저장`하며 사용할 수 있습니다.
+
+따라서 문서화를 할것이라면, 명시한 포맷에 맞는 문자열과 객체를 상호 전환할 수 있는 
+`정적 팩터리`나 `생성자`를 함께 제공해주면 좋습니다.
+
+#### 2) 문서화의 단점
+따라서 당연히 단점은 평생 그 포맷에 얽히게 된다는 점입니다.
+
+#### 결론 
+그렇기에 명시하던 아니던, 의도는 명확히 밝혀야 합니다. 
+포맷을 명시하려면, 아주 정확히, 포맷을 명시하지 않기로 했다면 `형식은 정해지지 않았으며 향후 변경될 수 있다`라는 문구를 추가해 명확히 달라질 수 있음을 이야기해야한다.
+
+### 🙌 주의점
+
+#### 1) 문서화 여부와 상관없이 toString이 반환한 값에 포함된 정보를 얻어올 수 있는 API를 제공하는 게 좋습니다.
+포맷이 되었다고 해서 해당 값에 접근할 수 있는 `getter` 가 없어서 `toString`에서 값을 파싱하는 건 성능이 나빠지고 필요하지도 않은 작업입니다.
+향후 포맷이 변경되면 이는 시스템이 망가지는 결과를 초래하기에 `getter`를 지원해주는 게 중요합니다.
+
+#### 2) 정적 유틸리티 클래스는 toString 제공할 필요 X
+#### 3) 대부분의 열거 타입도 자바가 이미 완벽한 toString 제공하니 따로 제공할 필요 X
+#### 4) 상위 클래스에서 이미 잘 재정의된 toString 이 있다면 제공할 필요 X
+#### 5) 다만!! 하위 클래스들이 공유해야할 문자열 표현이 있는 추상 클래스에선 정의 필요!!
+#### 6) AutoValue 프레임워크는 toString을 생성해주지만, 클래스의 의미가 중요한 경우 사용하지 않는 것이 좋음(ex PhoneNumber는 형식에 맞춰 반환 필요 / Potion은 자동 생성에 적합)

3장_모든_객체의_공통_메서드/아이템 13/clone 재정의는 주의해서 진행하라.md → 3장_모든_객체의_공통_메서드/아이템 13/clone_재정의는_주의해서_진행하라.md

@@ -109,8 +109,8 @@ Entry deepCopy(){
 > 좋은 방식은 아니다. 생성자에서는 재정의될 수 있는 메서드를 호출하지 않아야 하는데 clone 메서드도 마찬가지이기 때문이다.
 
 ### 주의점
-- 상속용 클래스의 경우 loneable을 구현해서는 안됨
-- 스레드 안전 클래스 작성 시 Clneable을 구현하는 모든 클래스는 clone을 재정의해야 함(접근 제한자는 pubic, 반환 타입은 클래스 자신)
+- 상속용 클래스의 경우 Cloneable을 구현해서는 안됨
+- 스레드 안전 클래스 작성 시 Cloneable을 구현하는 모든 클래스는 clone을 재정의해야 함(접근 제한자는 public, 반환 타입은 클래스 자신)
 
 ### 가능한 다른 선택지! 변환 생성자/ 변환 팩터리
 

3장_모든_객체의_공통_메서드/아이템 17/변경_가능성을_최소화해라.md

@@ -0,0 +1,139 @@
+## item 17
+
+### 변경 가능성을 최소화하라
+
+---
+
+### 🙋‍♀️ 왜 변경 가능성을 최소화하는 게 좋은가요?
+변경 가능성이 최소화된 클래스를 `불변 클래스`라고 합니다. 이는 인스턴스 내부 값을 수정할 수 없는 클래스로, 객체가 파괴되는 순간까지 절대 달라지지 않습니다.
+
+이런 클래스를 지향해야 하는 이유는 가변 클래스보다 설계하고 구현하고 사용하기 쉬우며,
+오류가 생길 여지도 적고, 안전하기 때문입니다.
+
+#### 1) 상대적으로 설계,구현,사용이 쉬움
+- 불변: 
+  - 프로그래머의 노력 없이도 영원히 불변으로 남음
+  - 값이 바뀌지 않는 상태이기에 구조가 아무리 복잡해도 불변식을 유지하기 쉬움 (실패 원자성)
+  - 불변 객체인 경우 불변 객체끼리는 내부 데이터 공유도 가능함
+- 가변: 메서드에 의해 임의의 복잡한 상태에 놓일 수 있음
+  - 따라서 가변 객체 사용시에는 클래스의 보안을 지키기 위해 진짜 해당 객체인지 확인해야 함
+
+#### 2) 스레드 안전
+- 근본적으로 스레드 안전하여 따로 동기화할 필요 X
+- 따라서 안심하고 공유가 가능하고, 그렇기에 최대한 재활용하는 게 좋음
+- 상수로 선언하거나, 정적 팩터리를 통해 생성하여 중복 생성을 피하고, 메모리 사용량/가비지 컬렉션 비용을 줄일 수 있음
+- 결국 추후에 나올 `방어적 복사`도 필요 없게 만듦(1번 장점에 해당)
+
+---
+
+### 🙋‍♀️ 불변 클래스는 어떻게 만들 수 있나요?
+
+아래의 다섯 가지 규칙을 잘 따르면 됩니다.
+#### 1) 객체의 상태를 변경하는 메서드를 제공하지 않는다.
+#### 2) 클래스를 확장할 수 없도록 한다. 하위 클래스에서 객체의 상태를 변하게 하는 것을 막아준다. (final 클래스로 정의 / 생성자를 private, package-private 정의)
+#### 3) 모든 필드를 `final`로 선언한다. 불변으로 명시적으로 선언하여 설계자의 의도를 명확히 들어낸다.
+#### 4) 모든 필드를 `private`로 선언한다. 필드가 참조하는 가변 객체를 클라이언트에서 직접 접근하여 수정하는 일을 막아준다. `public`으로 정의한 경우, 내부 표현을 쉽게 바꾸지 못하기에 `private`을 추천한다.
+#### 5) 자신 외에는 내부의 가변 컴포넌트에 접근할 수 없도록 한다. 클래스에 가변 객체를 참조하고 있는 필드가 있다면, 클라이언트에서 그 객체를 변경할 수 있다. 
+<details><summary>✅ 5번의 해결책 방어적 복사</summary>
+
+1) `List<String>` 가변 객체를 참조하는 필드가 있는 클래스에서, 해당 객체를 그대로 반환하고 있습니다.
+```java
+public final class ImmutableClass {
+    private final List<String> items;
+
+    public ImmutableClass(List<String> items) {
+        this.items = items;  // 가변 리스트를 직접 참조
+    }
+
+    // 가변 객체를 직접 반환
+    public List<String> getItems() {
+        return items;  // 외부에서 이 리스트를 수정할 수 있음
+    }
+}
+```
+
+2) 이 과정에서 문제가 발생합니다. 외부에서도 해당 객체의 내부 필드에 직접 접근하여 수정이 가능해지기 때문에 불변성을 보장받지 못하기 때문입니다.
+```java
+public static void main(String[] args) {
+    List<String> list = new ArrayList<>();
+    list.add("item1");
+    ImmutableClass immutable = new ImmutableClass(list);
+
+    // items 리스트를 직접 수정할 수 있음
+    List<String> retrievedList = immutable.getItems();
+    retrievedList.add("item2");  // 외부에서 리스트 수정 가능
+    System.out.println(retrievedList);  // [item1, item2]
+
+    // 원래 리스트도 수정됨
+    System.out.println(immutable.getItems());  // [item1, item2]
+}
+```
+
+3) 따라서 `방어적 복사`라는 것을 수행하라고 합니다. 가변 객체의 복사본을 저장하여 반환하는 방식입니다.
+```java
+public final class ImmutableClass {
+    private final List<String> items;
+
+    public ImmutableClass(List<String> items) {
+        this.items = new ArrayList<>(items);  // 가변 리스트의 복사본을 저장
+    }
+
+    // 가변 객체의 복사본을 반환
+    public List<String> getItems() {
+        return new ArrayList<>(items);  // 외부에서 수정할 수 없도록 복사본 반환
+    }
+}
+
+```
+
+4) 이렇게 되면 아까와 달리 외부에서 직접 수정이 가능하지만, 이가 내부 필드에는 영향을 미치지 않게 되어 불변성이 보장됩니다.
+```java
+public static void main(String[] args) {
+    List<String> list = new ArrayList<>();
+    list.add("item1");
+    ImmutableClass immutable = new ImmutableClass(list);
+
+    // items 리스트를 직접 수정할 수 있음
+    List<String> retrievedList = immutable.getItems();
+    retrievedList.add("item2");  // 외부에서 리스트 수정 가능
+    System.out.println(retrievedList);  // [item1, item2]
+
+    // 원래 리스트는 수정되지 않음
+    System.out.println(immutable.getItems());  // [item1]
+}
+```
+
+</details>
+
+---
+
+### 🙌 함수형 프로그래밍을 통한 불변 클래스 제작
+제목과 같이 함수형 프로그래밍을 통한 불변 클래스를 제작할 수 있습니다.
+
+<details><summary>✅함수형 프로그래밍과 절차적/명령형 프로그래밍의 차이</summary>
+
+#### 함수형 프로그래밍
+- 인스턴스 자신은 수정하지 않고 새로운 인스턴스를 만들어 반환하는 방식을 사용한 것으로, 
+실제 필드에는 영향이 없어 불변을 유지하는 프로그래밍 패턴
+- 불변이라는 점을 강조하기 위해 메서드 이름에도 동사 대신 전치사를 사용
+
+#### 절차적/명령형 프로그래밍
+- 인스턴스 자신을 수정하여 자신의 상태를 변화시키는 방식을 사용한 것으로, 
+- 실제 필드에 영향이 있기에 불변을 유지하기는 어려운 프로그래밍 패턴
+
+</details>
+
+### 🙋‍♀️ 그럼 불변 클래스의 단점은 없나요?
+다만 가변에 비해 성능(시간, 공간 문제)이 떨어지는 문제가 생길 수 있습니다.
+원하는 객체를 완성하기까지의 단계가 많고, 그 중간 단계에서 만들어진 객체들이 모두 버려진다면 성능 문제가 더 불거지게 됩니다.
+
+#### 1) 다단계 연산들을 예측하여 기본 기능으로 제공 (private 가변 동반 클래스를 활용)
+#### 2) 예측이 어렵다면, public 가변 동반 클래스로 제공
+
+하여 해당 단점을 보완해볼 수 있습니다.
+
+### 🙌 정리해보자면,
+1) 클래스는 꼭 필요한 경우가 아니라면 불변이어야 합니다.
+2) 불변으로 만들 수 없는 클래스라도 변경할 수 있는 부분을 최소한으로 줄여야 합니다.
+   3) 다른 합당한 이유가 없다면 모두 `priavte final`을 사용하는 게 좋습니다.
+4) 생성자는 불변식 설정이 모두 완료된, 초기화가 완벽히 끝난 상태의 객체를 생성해야 합니다.