김시용

1. 📌 핵심 개념 정리

✅ 요약하기

해당 챕터에서는 Args 클래스를 개선해 나가는 과정을 보여준다.

1. 초기 Args 클래스
   • Args 단일 클래스가 너무 많은 역할을 함

   스키마 해석, 인자 파싱, 값 저장, 타입 구분 모두 한 클래스에서 처리

   • 타입별 처리 로직이 중복

   Boolean, String, Integer 타입이 각각 따로 존재하며 중복된 방식으로 처리됨

   • 확장성 부족

   새로운 타입을 추가하려면 여러 곳을 직접 수정해야 함 -> OCP 위반

   • 에러 처리 방식이 직관적이지 않음

   예외 클래스 없음, 구체적인 오류 메시지 부족

   • 유닛 테스트가 어려움

   내부 메스드 분리나 구조화가 부족하여 테스트하기 어렵고 유지보수도 어렵다.

2. 완성 Args 클래스
   1. 동작하는 초기 클래스 구현
   2. 스키마 도입 및 일반화 (스키마를 도입하여 옵션과 그 타입을 정의, 이를 기반으로 인자를 파싱하도록 일반화)
   3. 각 타입별 처리 코드를 분리 (Boolean, Integer, String을 파싱하여 하나의 체계로 만들기)
   4. ArgumentMarshaler 패턴 도입 (이를 구현하는 타입별 처리 클래스 생성)
   5. 스키마 기반 처리 도입 (스키마를 문자열로 정의, 그것에 따라 인자를 해석하는 구조로 개선)
   6. 에러 처리 정비 (ArgsException 클래스 도입)

3. 최종 구조
   • Args : 명령줄 인자 파싱
   • BooleanArgumentMarshaler, IntegerArgumentMarshaler, StringArgumentMarshaler : 각 타입별 처리
   • ArgsException : 에러 처리
   • 스키마 문자열 (l, p#, d*) : 유연한 타입 정의

단일 책임, 확장성, 가독성, 재사용성 모두 갖춘 Args 클래스 완성

2. 🤔 이해가 어려운 부분

🔍 질문하기

책을 읽으며 이해하기 어려웠던 개념이나 명확하지 않았던 내용을 정리합니다.

1. 개념 또는 원칙의 이름
   • TDD
     클래스 개선 단계마다 테스트를 하여 동작되는지 매번 확인하기
   • 궁금한 점
     적절한 테스트 코드 작성법 궁금하다.

3. 📚 참고 사항

📢 논의하기

관련된 자료가 있다면 공유하고, 더 깊이 논의하고 싶은 아이디어나 의견을 정리합니다.

1. 논의하고 싶은 주제
   • 주제
     개선에 관한 큰 틀 및 방향은 어떻게 설계하는 것일까?
   • 설명
     초기 작동만 되는 Args 클래스를 만들고나서 확장성, 가독성 등에서 불편함을 직접 느끼고 이를 개선해나가는 방향으로 개선 방향을 정하는 것인가?