목표
클래스 분리, 리팩토링
신경 썼던 점 & 배운 점
- Enum으로 공통된 상수나 에러 관리
- RuntimeException들을 던지고 어디서 try-catch할 지??
- 객체를 단순히 저장소로 쓰지 않기(getter, setter뿐 아니라 도메인 로직 추가)
- 테스트 작성 시 @ParameterizedTest 활용하기
- 리팩토링이 필요한 상황에서 리팩토링
느낀 점 & 생각
- try-catch를 사용해서 RuntimeException을 처리해야 한다. 다만 요구 사항에서 메서드 10줄 이내가 있는 상황이고 예외가 발생하면 해당 부분을 재입력 받아야 한다. 따라서 반복문으로 감싸거나, 재귀 호출을 사용해서 try-catch를 작성해야 한다.
- 재귀적으로 호출할 시 성능상으로 반복문보다 훨씬 안좋고, Stack Overflow 리스크가 있다.
- InputView에서 예외 발생 및 처리까지 모두 하는 것이 좋은가? 우선은 InputView를 사용하는 Controller에서 private 메서드를 사용해서 처리했다.
- 리팩토링이 필요하다고 느낀 점은 처음이다.
- 평소 domain, repository, service, controller 이렇게 패키지를 나눴다. 하지만 이번에는 domain, view가 있고 그것을 모두 controller단에서 사용하도록 했더니 main과 controller가 매우 비대해졌다.
- domain을 사용하는 service를 추가로 만들어서 controller에서는 domain에 대한 의존성을 제거했다.
- controller에서는 view, service만 사용하고 대부분의 비즈니스 로직은 service에 존재한다. 매우 깔끔해졌다.
- try-catch를 반복문으로 처리하는 코드는 중복된다. 공통 로직을 분리할 수는 없을까? 커맨드 패턴 사용? abstract class에서 공통 로직을 구현해두고 안에서 interface에 의존하면 될 것 같은데 InputView 내에서만 Console.readLine()을 사용하라는 조건 때문에 불가능했다.
- 테스트하기 좋게 분리하는 건 아직 필요성을 느끼지 못하겠다. 테스트와 로직 구현을 동등하게 느끼지 못해서 그런 것 같다. 이번에 InputView에서 입력값의 유효성 검증 메서드를 private로 만들어뒀었는데, 그래서 테스트가 힘들었다. 분리할 수는 있었지만 하지 않았다.
- 함수를 엄청 분리한 사람들이 많던데 이 또한 필요성을 느끼지 못했다. 입력값 검증 메서드 -> 타입 검증 메서드, 범위 검증 메서드, 검증 메서드 통합....? 다른 검증 메서드에서도 사용될 로직이라면 분리하는 게 좋다고 생각하지만 그렇지 않다면 굳이 분리해야 하는가...?
渽晛