[1단계 - 로또 구현] 에드(김진우) 미션 제출합니다. #585
Conversation
- 구입 금액 입력 받는 함수 getPurchaseInput 구현
- 구매개수 출력 메서드 구현
- 기본 검증 메서드 구현(개수, 범위, 중복) - 당첨번호 일치, 보너스번호 일치 판단 메서드 구현
- 생성된 난수 오름차순 정렬하여 Lotto 객체 생성 - 구입 금액 유효성 검사 메서드 구현
- Lotto 클래스 내에 toDto 메서드 구현
- 싱글턴 패턴 적용 - 보너스 번호 중복 및 범위 유효성 검사 메서드 구현
- Lotto와 WinningLotto 객체의 양방향 메서드로 구현
- 분리된 메서든 간 데이터 전달을 위해 record를 사용
- toList()를 통한 List는 불변이므로 사전에 정렬 처리
- lotto -> basicLotto
- 가독성을 위해 for, if문에서 스트림으로 변경
|
안녕하세요 에드! 작성해주신 신경쓴 점에 대해 피드백 드려요 😄
|
|
|
||
| @ParameterizedTest | ||
| @MethodSource("provideInvalidLottoNumbersCount") | ||
| void 번호가_6개가_아니면_예외가_발생한다(List<Integer> numbers) { |
There was a problem hiding this comment.
다음 단계에서는 @DisplayName 에 대해 학습하고 사용해보아요!
|
|
||
| @ParameterizedTest | ||
| @MethodSource("provideValidLottoNumbers") | ||
| void 제대로된_번호가_오면_예외가_발생하지_않는다(List<Integer> numbers) { |
There was a problem hiding this comment.
서로 다른 4가지 경우의 수에 대해 테스트하고 있는데, 작성된 테스트를 읽는 것도 코드 유지보수 비용이랍니다.
4가지 모두 반드시 필요한 테스트일지 고민해보아요. 🙂
|
|
||
| public class LottoFactory { | ||
| public static Lotto createLotto(List<Integer> numbers) { | ||
| return new Lotto(numbers); |
There was a problem hiding this comment.
LottoFactory#createLotto 는 사실상 Lotto 생성자를 한 번 감싼 형태인데요~ 해당 메서드가 필요한 이유가 무엇일까요?
다른 Factory 클래스들도 꼭 필요한 것인지 고민해보아요 😄
There was a problem hiding this comment.
서비스 레이어에서 모델 객체를 직접 new를 통해 생성하기보다 팩토리 클래스를 둠으로써 객체 생성의 책임을 한 곳에서 관리하려 했던 것 같습니다!
엘리의 리뷰를 보고 다시 고민해보니, 현재 Lotto를 비롯한 모델 객체들의 생성 방식이 단순한 편이라 "객체 생성"이라는 책임이 그렇게 무겁지 않음을 깨달았습니다.
즉, 모든 모델 객체에 팩토리 패턴을 적용할 필요는 없을 것 같고, Lottos나 Statistics와 같은 모델에는 팩토리 클래스를 따로 두지 않는 방향이 더 적절할 것 같습니다.
다만, LottoFactory의 경우 다음과 같이 리팩토링 한다면 유지하는 것이 의미가 있을 것 같습니다.
실제 로또 시스템에서는 자동/수동을 선택하여 구매할 수 있으며, 현재 프로젝트 요구사항에서도
사용자가 구매한 로또 → 자동 생성
지난주 당첨 로또 → 수동 생성
이 적용되므로, 생성 방식을 분리하는 것이 팩토리 패턴을 적용할 이유가 될 수 있다고 생각했습니다.
💡 리팩토링 방향
public class LottoFactory {
// 수동 로또 생성
public static Lotto createLotto(List<Integer> numbers) {
return new Lotto(numbers);
}
// 자동 로또 생성
public static Lotto createRandomLotto() {
List<Integer> randomNumbers = RandomGenerator.generateNumbers(1, 45, 6); // 유틸 호출
return new Lotto(randomNumbers);
}
}이렇게 변경하면,
현재는 객체 생성 방식이 2가지(자동/수동)로 나뉜 것이지만
추후 로또 생성 방식이 더 확장되더라도 쉽게 적용할 수 있는 구조를 가질 수 있다는 점에서 팩토리 패턴이 의미를 가질 수 있을 것 같습니다!
피드백 주시면 감사하겠습니다! 🙏😊
| for (Integer number : numbers) { | ||
| if (number < 1 || number > 45) { | ||
| throw new IllegalArgumentException(ErrorMessage.NUMBER_OUT_OF_RANGE.getMessage()); | ||
| } | ||
| } |
There was a problem hiding this comment.
규칙 1: 한 메서드에 오직 한 단계의 들여쓰기(indent)만 한다. 규칙에 맞게 고쳐볼까요~?
| public void addLotto(Lotto lotto) { | ||
| lottos.add(lotto); | ||
| } |
There was a problem hiding this comment.
일급컬렉션의 중요한 특징 중 하나는 컬렉션의 불변을 보장한다. 입니다.
addLotto 메서드는 lottos 에 변경을 가하고 있네요! 😅
일급컬렉션의 목적에 맞게 코드를 수정해볼까요?
참고 블로그 : https://jojoldu.tistory.com/412
|
|
||
| public class LottoFactory { | ||
| public static Lotto createLotto(List<Integer> numbers) { | ||
| return new Lotto(numbers); |
There was a problem hiding this comment.
서비스 레이어에서 모델 객체를 직접 new를 통해 생성하기보다 팩토리 클래스를 둠으로써 객체 생성의 책임을 한 곳에서 관리하려 했던 것 같습니다!
엘리의 리뷰를 보고 다시 고민해보니, 현재 Lotto를 비롯한 모델 객체들의 생성 방식이 단순한 편이라 "객체 생성"이라는 책임이 그렇게 무겁지 않음을 깨달았습니다.
즉, 모든 모델 객체에 팩토리 패턴을 적용할 필요는 없을 것 같고, Lottos나 Statistics와 같은 모델에는 팩토리 클래스를 따로 두지 않는 방향이 더 적절할 것 같습니다.
다만, LottoFactory의 경우 다음과 같이 리팩토링 한다면 유지하는 것이 의미가 있을 것 같습니다.
실제 로또 시스템에서는 자동/수동을 선택하여 구매할 수 있으며, 현재 프로젝트 요구사항에서도
사용자가 구매한 로또 → 자동 생성
지난주 당첨 로또 → 수동 생성
이 적용되므로, 생성 방식을 분리하는 것이 팩토리 패턴을 적용할 이유가 될 수 있다고 생각했습니다.
💡 리팩토링 방향
public class LottoFactory {
// 수동 로또 생성
public static Lotto createLotto(List<Integer> numbers) {
return new Lotto(numbers);
}
// 자동 로또 생성
public static Lotto createRandomLotto() {
List<Integer> randomNumbers = RandomGenerator.generateNumbers(1, 45, 6); // 유틸 호출
return new Lotto(randomNumbers);
}
}이렇게 변경하면,
현재는 객체 생성 방식이 2가지(자동/수동)로 나뉜 것이지만
추후 로또 생성 방식이 더 확장되더라도 쉽게 적용할 수 있는 구조를 가질 수 있다는 점에서 팩토리 패턴이 의미를 가질 수 있을 것 같습니다!
피드백 주시면 감사하겠습니다! 🙏😊
싱글톤이 아니게 된다면 이미 당첨 로또 객체가 존재하더라도 다른 객체가 추가로 생성될 수 있다는 위험성이 증가하고 한번 생성한 뒤에 해당 당첨 로또 객체를 계속 들고 다니며 코드를 작성해야한다는 단점이 있을 것 같습니다! 싱글톤을 유지하면서 테스트를 구현할 방법으로 테스트에서 어려움이 있었던 만큼, 싱글톤을 유지하는 것보다 서비스 레이어에서 1회만 생성 후 주입하는 방식으로 변경하는 것이 더 나은 선택일까요?? |
- createCustomLotto는 당첨 로또 생성시, createRandomLotto는 사용자 구매 로또 생성시 사용
- Lottos 객체 생성의 경우 별도의 복잡한 로직이나 여러개의 방식을 제공하지 않으므로 서비스 레이어에서 직접 new로 생성하는 방식으로 변경
- Statistics 객체 생성의 경우 별도의 복잡한 로직이나 여러개의 방식을 제공하지 않으므로 서비스 레이어에서 직접 new로 생성하는 방식으로 변경
신경쓴 점
Prolog 링크
Prolog
java-lotto
로또 미션 저장소
입력
도메인
로또 발행
당첨 판단
출력