[2단계 - 자동차 경주 리팩토링] 성하(김성훈) 미션 제출합니다. #624
Conversation
|
그리고 RacingCars 멤버 변수를 선언하는 것에 대해서 외부 사용자 A, B가 있고 제가 이런 부분은 겪어보지 못해서 잘 모르는데 이런 상황 예시가 적절한 건가요?! |
| private boolean isBlankName(String carName) { | ||
| return carName.equals(""); | ||
| } |
There was a problem hiding this comment.
String.isBlank를 사용할 수도 있을것같아요.
그리고 이런 경우엔 "".equals(carName)과 같이 사용해야 NPE를 피할 수 있답니다!
There was a problem hiding this comment.
오 String에 isBlank() 가 따로 존재하는지 몰랐는데
항상 있을 법한 기능은 찾아보는 습관을 들여야겠네요! 감사합니다!
NPE도 예상을 못한 부분인데 짚어주셔서 감사합니다!
| private void validateName(String name) { | ||
| if (isWrongNameLength(name)) { | ||
| throw new IllegalArgumentException(CAR_NAME_LENGTH_ERROR); | ||
| } | ||
| if (isBlankName(name)) { | ||
| throw new IllegalArgumentException(SPLIT_CAR_NAME_BLANK_ERROR); | ||
| } | ||
| } |
There was a problem hiding this comment.
검증하는 부분을 해당 객체로 옮기셨군요 👍🏻 기존과 어떤점이 다르게 느껴지셨나요?
There was a problem hiding this comment.
InputView 단이 아닌 도메인 객체로 옮기니 검증하는 의미가 명확해진 느낌이 들었습니다!
'자동차' 이름에 대한 검증인 만큼 '자동차' 객체가 검증 로직을 가지고 있는 것이 더 객체지향 관점에서 맞는 것 같아요!
해당 어플리케이션 코드를 처음 보는 개발자가 봤을 때에도
'자동차 이름에 대한 검증 로직은 어딨지?' 라고 생각할 때,
저라도 InputView보다는 Car 객체를 먼저 들여다 볼 것 같습니다.
또, InputView에 도메인 검증에 관한 로직을 생성하면 지금은 자동차 객체밖에 없지만,
추후에 도메인이 추가되어 여러 객체가 있을 때 여러 도메인에 관한 검증 로직을 InputView에서 처리하는 것이
단일 책임 원칙에 위배된다는 느낌도 받았습니다!
현재 코드에서 아쉬운 점은, 비즈니스 로직에 검증 로직도 포함되지만
실제 핵심 기능(자동차 객체에서 전진 기능 같은)과 검증 로직이 함께 도메인 객체에 존재한다는 것이 조금 신경이 쓰였습니다.
지금은 핵심 기능과 검증 로직이 몇 가지 되지 않아 코드가 길어지지 않았지만
추후에 확장되어 기능이 많아진다면 복잡해질 것으로 생각이 들었습니다!
우연히 조원의 코드를 보았는데, 똑같이 도메인에 검증 로직을 구현했지만
자동차 이름을 원시값 포장하여 새로운 Name 객체로 만들어서
해당 Name 객체에 검증 로직을 옮긴 것을 봤습니다.
이렇게 하니 제가 신경쓰였던 검증 로직도 핵심 기능 로직과 분리할 수 있었고 원시값도 포장되는 효과가 있더라고요!
다음 미션 도메인 검증 시에는 이와 같은 방법으로 구현해보려고 합니다!!
이러한 깊은 생각을 하게 해주셔서 감사합니다! 몰랐으면 넘어갔을 것 같아요! 😄
|
#624 (comment) 에 대한 답변입니다. 말씀해주신 경우가 맞습니다! 지금엔 이런게 있다 정도로만 넘어가시고 나중에 웹 미션을 진행하시면서 더 자세히 알아보시면 좋을것같아요 👍🏻 |
1단계에서 InputView단에 있던 자동차 이름 검증 로직을
도메인 로직에 옮겨 리팩토링하게 되었습니다.
리팩토링 중에 '분리한 자동차 이름이 중복되는 경우 예외 처리' 부분은
RacingCars에서 처리하기가 힘들어서 InputViewValidator에 남겨두게 되었습니다!
리뷰 남겨주시면 감사하겠습니다!