4단계 - 수강신청(요구사항 변경)

[sunggyupaik]

학습 관리 시스템(Learning Management System)

4단계 - 수강신청(요구사항 변경)

변경된 기능 요구사항

• 강의 수강신청은 강의 상태가 모집중일 때만 가능하다.
  • 강의가 진행 중인 상태에서도 수강신청이 가능해야 한다.
    • 강의 진행 상태(준비중, 진행중, 종료)와 모집 상태(비모집중, 모집중)로 상태 값을 분리해야 한다.
• 강의는 강의 커버 이미지 정보를 가진다.
  • 강의는 하나 이상의 커버 이미지를 가질 수 있다.
• 강사가 승인하지 않아도 수강 신청하는 모든 사람이 수강 가능하다.
  • 우아한테크코스(무료), 우아한테크캠프 Pro(유료)와 같이 선발된 인원만 수강 가능해야 한다.
    • 강사는 수강신청한 사람 중 선발된 인원에 대해서만 수강 승인이 가능해야 한다.
    • 강사는 수강신청한 사람 중 선발되지 않은 사람은 수강을 취소할 수 있어야 한다.

프로그래밍 요구사항

• 리팩터링할 때 컴파일 에러와 기존의 단위 테스트의 실패를 최소화하면서 점진적인 리팩터링이 가능하도록 한다.
• DB 테이블에 데이터가 존재한다는 가정하에 리팩터링해야 한다.
  • 즉, 기존에 쌓인 데이터를 제거하지 않은 상태로 리팩터링 해야 한다.

[sunggyupaik]

안녕하세요, 재성님께도 한번 피드백 받고 싶어서 보완해 pull request 했습니다~!
5번째 라이브 강의를 계속 돌려보며 엔티티와 비지니스 로직을 어떻게하면 적절하게 분리할 수 있을지 고민했습니다.

Session과 NsUser 테이블의 중간 테이블은 Apply 입니다.

강의 준비중, 강의 진행중, 강의 종료 등 상태 변경은 간단한 로직으로 생각해 Session에서 처리했습니다.

강의 신청은 유효성 검증이 많다고 판단하여 Enrollment 클래스에 별도로 분리하여 처리했습니다.

강의 승인 및 취소도 검증을 위해 ApproveCancel 클래스에 별도로 분리하여 처리했습니다.

getter의 get 명칭을 제거하고, 각 변수는 final로 선언하며 setter를 사용하지 않고 구현하였습니다.

클래스가 너무 많은 변수를 가지지 않도록 분리하기 위해 고민했습니다.(최대 4개, Image는 5개)

일급 컬렉션을 적극 사용하여 로직이 너무 한 클래스에 과도하지 않도록 했습니다.

테스트를 위해 별도의 fixture를 생성해 과도한 중복 코드를 줄였습니다.

이번 과제에서 어떤 부분들을 중점적으로 학습해야하는지 피드백 주시면 감사하겠습니다!