4장 타입코드 처리하기

4-1 간단한 if 문 리팩터링

• 타입검사 이외의 if-else 문을 하드코딩된 결정으로 볼 수 있다는 관점이 신기했다.
• if 대신 객체&인스턴스를 활용해보기
• enum 대신 인터페이스 사용해보기

4-2 긴 if 문의 리팩터링

• 열거형을 인터페이스로 분리

4-2-1 일반성 제거

4-2-2 메서드 전문화

4-2-3 switch가 허용되는 유일한 경우

• switch 를 이용해 열거형 인텍스를 이용해 데이터베이스나 파일에 무엇인가를 저장하느라 사용할 때 ⇒ 이거 맞게 이해한건가??
• ⁉️ 이 예제가 헷갈려서 여러 번 계속 보게 됨

4-2-4 규칙: switch를 사용하지 말 것

• defalt 케이스가 없고 모든 case에 반환 값이 있는 경우가 아니라면 사용하지 말 것
• 💡 defalt 에 값을 저장하는 것이 if-else를 지양하라는 것과 같은 맥락같다. 모든 조건을 생각하기 귀찮아서 else나 defalt 로 책임을 전가하곤 했는데 이를 조심해야 할 것 같다.

4-2-5 if 제거하기

• 앞에서 배운 클래스로 이관패턴 적용 & 메서드의 인라인화(한줄이라서!) 적용해 본 예제

4-3 코드 중복처리

• 앞에서 배운 클래스로 이관패턴 적용 & 메서드의 인라인화(한줄이라서!) 적용해 본 예제2

4-3-1 인터페이스 대신 추상클래스를 사용해 공통코드로 관리 할 수는 없을까?

• 있지만 권장하지 않는다. ⇒ 이후 유지보수하기 힘듦(결합도가 높아짐, 재정의가 필요한지 컴파일러가 잡기 힘듦)
• 인터페이스에서만 상속받는 것을 권장한다.

4-3-2 규칙: 인터페이스에서만 상속받을 것!

• 보통 코드를 복제해서 조금만 변형해서 쓰는 건 코드중복이 발생해 안 좋다고 알고 있었는데 여기선 그걸 권장해서(이런 의문조차 언급됨) 의외였음. 과연 어떤 식으로 설명하려고 그러나,, 하게 됨.

4-4 복잡한 if 체인 구문 리팩터링

• 예제

4-5 필요없는 코드 제거하기

4-5-1 리팩터링 패턴 : 삭제 후 컴파일하기

• IDE를 적극적으로 활용하는 방법같다. 도구 활용도 능력인 듯!
• 인터페이스는 IDE에 사용여부가 안나온다는 점이 조금 아쉽,,

요약

이번 장에는 많은 내용들이 들어가고, 여러번 같은 내용들을 실습하는 내용들이었다. 기억해두기!!

• if문에서 else를 사용하지 말 것, switch를 사용하지 말 것 ⇒ 클래스로 타입코드 대체 & 클래스로의 코드이관 방법 이용하기
• 지나치게 일반화 된 메서드 → 리팩터링에 방해 ⇒ 메서드 전문화 리팩터링 실시
• 인터페이스에서만 상속 받을 것
• 메서드의 인라인화 & 삭제 후 컴파일하기

느낀 점

이번 장은 길기도 하고 예제도 많아서 읽기 힘들었다.
클래스로 타입코드 대체 & 클래스로의 코드 이관 방법을 여러 예제를 통해 보여줬는데 
처음엔 왜 이렇게 계속 코드길어지게 나누지,, 중복이 많이 발생하네,, 했었다. 
그런데 계속 읽고보니 분리한 메서드들이 각 클래스들 안에서 각자의 역할을 하고 
낮아진 결합도를 보니 생각보다 분리한 것이 코드가 길어지는 것 만이 아닐 수 있겠다는 생각이 들었다.
추후 리팩토링을 위해 고려해야 할 범위와 연관으로 인한 오류의 위험이 낮아진 것 같다.
해당 바람직한 꼴을 눈에 읽혀 스멜을 잘 맞을 수 있도록 연습해봐야겠다.