16장 SerialDate 리팩토링 정리 (#20)

Chapter 16. Refactoring SerialDate/yangyunhyeuk.md

@@ -0,0 +1,46 @@
+## 16장 SerialDate 리팩터링
+
+### 첫째 돌려보자
+
+- SerialDateTests라는 클래스는 단위 테스트 케이스 몇 개를 포함한다. 돌려보면 실패하는 테스트 케이스는 없다. 하지만 테스트 케이스를 훑어보면 모든 경우를 점검하지 않는다는 사실이 드러난다.
+- 클래스를 철저히 이해하고 리팩토링하려면 훨씬 높은 테스트 커버리지가 필요하다.
+- 경계 조건 오류가 존재하며 논리적 오류로 인해 실행되지 않는 코드도 존재한다.
+
+### 둘째 고쳐보자
+
+- 주석
+    - 법적인 정보는 필요하므로 라이선스 정보와 저작권은 보존한다.
+    - 소스 코드 제어 도구를 사용하므로 변경 이력은 없애도 된다.
+- import 처리
+    - java.text.*, java.util.*로 import 문을 간결화할 수 있다.
+- Serial이란 단어가 들어가는 이유
+    - 클래스 이름이 SerialDate인 이유는 일련번호를 사용해 클래스를 구현했기 때문이다. 여기서는 1899년 12월 30일을 기준으로 경과한 날짜 수를 사용한다.
+        - 꺼름칙한 부분
+            1. 일련번호라는 용어는 정확하지 못하다. SerialDate가 그다지 서술적인 이름이 아니며 좀 더 서술적인 이름으로는 서수(ordinal)가 있다. 
+            2. SerialDate라는 이름은 구현을 암시하는데 실상은 추상클래스이다. 구현을 암시할 필요가 전혀 없는 것으로 추상화 수준의 의미를 나타내기에는 올바르지 못하다. 
+    - 저자는 고민 끝에 DayDate를 쓰기로 결정했다.
+- Enum 사용
+    - MonthConstants를 상속하고 있는데, static final 상수 모듬에 불과하다.
+    - MonthConstants를 Enum으로 변경하여 사용하는 것이 마땅하다.
+- SerialVersionUID 변수는 직렬화를 제어한다.
+    - 이 변수 값을 변경하면 이전 SW 버전에서 직렬화한 DayDate를 더 이상 인식하지 못한다.
+        - 역직렬화 시 InvalidClassException 발생
+    - serialVersionUID 변수를 선언하지 않으면 컴파일러가 자동으로 생성하지만 모듈 변경시 자동으로 달라진다.
+    - 문서에서는 직접 선언을 권장하지만 저자는 컴파일러의 자동 제어가 훨씬 더 안전하다 여긴다. 따라서 특정 버전에서 직렬화한 클래스를 다른 버전에서 복원하지 않는 편이 안전하다.
+- 변수 위치
+    - 책임이 존재하는 클래스와 관계가 없는 변수는 제거하거나 관련된 책임이 있는 클래스로 옮겨야 한다.
+- 기반 클래스와 파생 클래스
+    - 일반적으로 부모(기반) 클래스는 파생(자식) 클래스를 몰라야 바람직하다.
+    - 추상 클래스는 구체적인 구현 정보를 포함할 필요가 없다.
+    - 추상 팩토리 패턴을 적용하여 객체를 생성하도록 하자
+- 접근 제어자
+    - 외부에 공개될 필요가 없는 경우에는 접근 제어자를 private으로 변경
+- final 키워드
+    - 실질적인 가치는 없으나 코드는 복잡하게 만들기에 인수와 변수 부분에서 모두 제거한다.
+    - 로버트 시몬스는 코드 전체에 final을 사용하라고 권장한다.
+- 중첩 if문
+    - 보기 좋지 않아 하나의 조건문으로 만들어 중첩은 제거하도록 하자
+
+### 결론
+
+- 보이스카우트 규칙에 따라 버그 및 코드 크기를 줄였으며 좀 더 쉽게 이해할 수 있는 코드로 개선하였다.