4주차 과제를 돌아보며
시간
과제 소요 시간 : 목~수 7일간 약 60시간 + 회고글 n시간
wakatime 으로 봤을 때, 7일간 IDE에 커서가 머무른 시간이 약 38시간이다.
설계에 한 3시간 쓴 것 같고, 나머지 시간은 학습에 사용했다. 주로 도메인 객체의 역할과 범위, SRP 원칙과의 충돌, 상태 관리의 주체, 제네릭의 조건 설정 등에 대해서 학습을 진행했다.
구현 정도
기능 요구 사항, 프로그래밍 요구 사항, 과제 진행 요구 사항 전부를 만족했고, 테스트를 통과했다.
클래스 다이어그램
내가 작성한 전체 코드의 클래스 다이어그램이다.
특이한 점은 전략 패턴을 2군데(입력값의 메뉴 자동 분류, 할인 적용)에 사용했고, 평균적으로 하나의 도메인 객체가 하나의 서비스 클래스와 연관된다. 도메인 객체가 할 일이 많으니 상대적으로 서비스 클래스의 수가 줄게 되었다. 그리고 전체적으로 깔끔한 연관관계를 가진다.
과제에 새로 사용해보거나 적용한 것들
도메인 객체
도메인 객체 스스로가 상태와 관련된 비즈니스 로직을 가짐
서비스 레이어는 비즈니스 로직만 수행
DTO는 필요할 때만 생성
int 타입의 큰 수는 _ 로 가독성 향상 (예 : 1_000_000)
컨텍스트 사용(할인에 필요한 정보를 담음)
...
소감
매우 만족했던 4주차였다.
가장 먼저, 3주차와 달리 내가 쏟아부을 수 있는 모든 시간을 과제에 쏟아부어서 좋았고, 그 만큼 후회도 남지 않는다. 물론 개선의 여지는 당연히 있지만, 최대한의 노력과 시간을 투자했기 때문에 후회하지 않는다.
결과물도 만족한다. 객체를 객체스럽게 사용해라 라는 피드백을 많이 고민했고, 학습하고 과제에 적용해보려 노력했다. 그 결과 많은 연관관계나 흐름 조정을 위한 서비스 클래스가 따로 필요하지 않았다. 존재하는 서비스 클래스들도 매우 간결하다. 이전과 달리 많은 상태를 가지지도 않는다.
그리고 재밌었다. 과제 난이도의 상승은 곧 많은 학습의 기회와 승부욕의 제공을 의미한다. 요구사항이 많아 한 기능을 구현할 때 이후에 영향을 미칠 다른 기능들과의 조합을 생각하는 것도 재미있었다. 머리 쓰는걸 좋아해서 그런 것 같다. 복잡한 논리 퀴즈, 스도쿠를 푸는 기분이었다.
