Skip to main content

김시용

1. 📌 핵심 개념 정리

✅ 요약하기

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

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

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

    • 타입별 처리 로직이 중복

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

    • 확장성 부족

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

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

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

    • 유닛 테스트가 어려움

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

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

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

2. 🤔 이해가 어려운 부분

🔍 질문하기

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

  1. 개념 또는 원칙의 이름
    • 어려웠던 부분TDD
      해당클래스 개념이선 헷갈리거나단계마다 명확테스트를 하여 동작되는지 않았던매번 점을 구체적으로 설명합니다.확인하기
    • 궁금한 점
      해당적절한 개념이테스트 어떤코드 원리로작성법 동작하는지, 실무에서 어떻게 활용되는지 등을 질문 형태로 정리합니다.
  1. 개념 또는 원칙의 이름
    • 어려웠던 부분
      .
    • 궁금한 점
      .
  1. 개념 또는 원칙의 이름
    • 어려웠던 부분
      .
    • 궁금한 점
      하다.

3. 📚 참고 사항

📢 논의하기

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

  1. 관련 자료 공유
    • 추가 자료
      관련 블로그 글이나 공식 문서 링크를 제공합니다.
  1. 논의하고 싶은 주제
    • 주제
      논의하고개선에 싶관한 큰 틀 및 방향은 내용을어떻게 간략히설계하는 정리합니다.것일까?
    • 설명
      논의하초기 작동만 되는 Args 클래스를 만들고나서 확장성, 가독성 등에서 불편함을 직접 느끼고 싶은 이유를 작성합니다.개선해나가는 방향으로 개선 방향을 정하는 것인가?
Back to top