3주차 회고
이번 로또 과제를 진행하면서 저번 과제 보다는 많은 요구사항들이 있었고 그만큼 흐름잡기나 각 클래스의 책임을 부여하는 과정들이 오래 걸렸고 요구사항들을 꼼꼼히 분석하지 못하여 예외를 잡는 부분등을 고려하지 않고 개발을 했다가 큰코를 다쳐가며 ㅋㅋㅋㅋ 열심히 구현을 해봤다.
PR link
Controller
프로그램의 전반적인 진행 흐름을 제어하는 역할을 한다.
- LottoMachinController
- 전체 게임 흐름을 제어한다.
1 |
|
View
컨트롤러로부터 데이터를 넘겨받아 출력하는 OutputView, 사용자로 부터 데이터를 입력 받아 컨트롤러로 넘기는 InputView
Model
상태를 변경 관리 조회를 담당하는 역할을 한다.
- Lotto
- Lotto 번호를 가지고 있고, 로또와 관련된 예외 검증 로직과, 파라미터로 들어오는 번호와 몇개 일치하는지 반환하는 로직 포함
- BonusNumber
- int value를 가지고 있는 값 객체, 보너스 번호와 관려된 예외 검증 로직검증 포함
- WinningLotto
- Lotto와 BonusNumber를 가지고 있고, 로또 번호와 당첨 번호를 비교하여 결과를 반환하는 역할을 맞고 있다.
- CustomerLotto
- 고객의 로또들을 가지고 있는 일급 컬렉션으로 당첨 로또를 고객의 로또 티켓들과 비교하는 역할을 한다. 내부에서 stream을 돌면서 WinningLotto:checkLotto를 수행하여 LottoResults를 반환한다.
Constance
- Rank
- 각 랭크에 맞는 일치 개수(ex 1등은 6개 모두 일치), 보너스 번호 일치 여부, 상금, 해당 랭크이기 위한 조건을 가지는 enum 클래스
공부 한 내용
1. BiFunction<> 사용
1 |
|
이번 과제 구현시 Rank enum 클래스에서 BiFuntion이라는 함수형 인터페이스를 사용했다.
2개의 인자를 받아 BiFuntion에 구현된 내용이 수행된다.
각 랭크별로 조건들을 지정해두고 해당 조건이 만족하면 True를 반환하고 아니라면 False를 반환한다.
1 |
|
- SECOND는 (count, bonus) -> count == 5 && bonus일 때 true를 반환한다.
2. @ParameterizedTest -> @MethodSource 사용
1 |
|
@MethodSource(“함수명”)
private static Stream<Arguments> provideLottoRankTestCases(){}
사전에 지정해둔 함수안에 Stream.of(Argument.of())를 사용하여 테스트의 파라미터로 매핑이 되어 테스트를 진행한다.
많은 중복되는 내용을 테스트 할 때 각각을 따로 만드는 방식보다 효율적이다.
3. 의도적인 분리가 아닌 분리해야 할 때 클래스 분리
개인적으로 저는 클래스로 분리할 때는 한 클래스가 너무 많은 역할을 가지고 있거나, 테스트 코드를 작성할 때 테스트 하고 싶은 기능이 있을 때 해당 기능이 private 메서드 일때 클래스를 분리하는게 어떨까?라고 생각을 하는 편이다
기존 WinningLotto는
1 |
|
이렇게 구현이 되어있었다. 하지만 검증하는 부분을 보면 뭔가 이상하다… 분명 WinningLotto 클래스 만드는 부분인데 bonusNumber에 대해서만 검증을 진행하고 있다. Lotto는 이미 검증이 끝난 상태이다. WinningLotto에서 bonusNumber에 대해 검증을 하고 있다? 아 분리해야겠다
1 |
|
1 |
|
이렇게 분리하니 BonusNumber 클래스에서 검증을 진행할 수 있게 되었고 예외 사항 테스트 하기에도 유리하게 바뀌었다.
3주차 소감문
1 |
|