Scheduler 과제 복습
- API 설계
- API 설계부터 다시했다. 최초 과제를 제출할 때는 어떤 메소드를 사용하고, @RequestBody @RequestParam @PathVariable과 같이 입력을 어떻게 받아올지와 어떤 양식으로 받아올지를 정했다면, 이번 API 설계에는 한 뎁스 더 나아가, Controller > Service > Repository로 흐를 때 입/출력 데이터의 양식과 메소드 정의도 포함시켰다.
- 이렇게 한 이유는, API 설계만으로는 메소드가 어디에서 어디로 흐르고, 입력과 출력의 형태는 무엇인지가 모호했고, 나름 정의하고 시작했다고 생각했음에도 코드를 짜면서 오류가 나니 강의에서 실습한 메모를 보고 따라하는 수준에 머무름을 느꼈기 때문이다.
- 이렇게 입력부터 Controll > Service > Repository > Service > Controll의 흐름을 정리하니, 구조가 머릿속에 들어오기 시작했다. 역시 직접 해봐야한다.
- 실제로 코드를 짜다보니, 일부 실수한 부분도 있었다. @GetMapping을 해놓고 @RequestBody를 한다거나(id 조회), 혹은 @PatchMapping을 해놓고 RequestParam으로 받는다거나. 이런 부분이 찰떡같이 이루어지지 않은 점을 보면 구조와 개념을 완벽하게 이해했다고 보기는 어렵다.
- AllArgsContructor의 기능을 이제야 알 것 같다. 과제를 제출할 때 ResponseDto의 생성 입력은 Schedule 타입인데, 왜 Repository에서 저장(saveSchedule)하고 반환할 때 Schedule을 넣지 않고 요소들을 넣었음에도 ResponseDto가 생성되는지 궁금하다고 적어 냈다.
- 생각해보니, AllArgsContructor가 Schedule이 통으로 들어오지 않아도, Schedule이 갖고 있는 Arguments가 입력으로 들어오면 생성하도록 해주는 Lombok인 것 같다.
- Dr.G한테 물어보니, 맞게 이해했다고 한다. 엄밀히 말하면, 모든 속성을 갖는 생성자를 자동으로 생성해주는 Lombok이라고 한다.
- 이렇게 하나씩 깨우쳐가는 느낌 좋다. 도전 과제는 완수하지 못했지만, 숙련주차 과제를 보니 입문 과제에서 도전이었던 내용이 필수 과제로 포함되어 있는 것 같았다. 강의 잘 듣고, 잘 따라가봐야겠다.
Experience