[그리디] 강대현 사다리 미션 1~5단계 제출합니다.#91
Open
Kdahyn wants to merge 17 commits intonext-step:kdahynfrom
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
🙋♂️ 인사
안녕하세요, 해윤님😊 백엔드 4기 강대현입니다. 잘 부탁드립니다!
🚗 구현 내용
1, 2단계
3, 4, 5단계
🤔 고민한 내용
printResult에서 컨트롤러의 책임 범위가 어디까지인지 고민했습니다. 현재는 컨트롤러가 View와 DTO를 연결하고, 사용자가 입력한all명령을 해석하는 책임까지 가지도록 구현했습니다.Connection클래스로 분리할지 고민했지만, 현재는ConnectionGenerator를 통해 연결 여부를생성하는 방식으로 구현했습니다.
PrizeResult목록을PrizeResults라는 일급 컬렉션으로 감싸서, 컨트롤러에서 직접 결과 목록을 다루지 않도록 했습니다.TestConnectionGenerator를 만들었습니다. 미리 정해 둔 연결 값을 순서대로 반환하도록 하여예측 가능한 사다리를 생성할 수 있게 했습니다.
❓ 질문사항
printResult를 작성하는 과정에서 들여쓰기 깊이를 1 이하로 유지하기 위해 메서드를 분리했습니다.그런데
while하나만 감싸는 메서드가 꼭 필요한지 고민이 되었습니다.또한
retryUntilValid내부에는while과try-catch가 함께 있어 들여쓰기 깊이가 생기는데, 이런 공통 예외 처리 메서드까지동일한 기준으로 더 분리해야 하는지도 궁금합니다.
객체 생성을 생성자보다 정적 팩터리 메서드를 통해 처리하려고 했습니다.
그래서 가능하면 생성자는
private으로 두고, 정적 팩터리 메서드에서 검증이 완료된 객체를 생성하는 방향으로 구현했습니다.다만
Players는LadderGame에서 사다리를 탄 이후의 플레이어 목록을 다시 만들기 위해 생성자를public으로 두었습니다.이 경우 다른 곳에서 의도한 정적 팩터리 메서드 대신 생성자를 직접 사용할 가능성이 생긴다고 생각했습니다.
이런 경우에도 생성자를 열어두는 것이 괜찮은지, 아니면 별도의 정적 팩터리 메서드를 추가하는 편이 더 좋은지 궁금합니다.
Row를 생성할 때true다음에는 자동으로false를 추가하여, 가로선이 연속으로 생성되지 않도록 구현했습니다.현재 방식은 규칙을 만족하기는 하지만, 생성 과정에서 값을 건너뛰거나 추가하는 방식이라 조금 어색하게 느껴졌습니다.
가로선이 연속되지 않도록 보장하는 더 자연스러운 설계나 구현 방식이 있을지 궁금합니다.
PrizeResult목록을 일급 컬렉션인PrizeResults로 만들고dto패키지에 위치시켰습니다.그런데
PrizeResults가 단순히 데이터를 전달하는 역할뿐 아니라, 이름으로 결과를 찾는findByName같은 조회 책임도가지고 있습니다.
이 정도의 책임을 가진 객체를 DTO로 보아도 괜찮은지, 아니면 도메인 또는 다른 패키지로 분리하는 것이 더 적절한지 궁금합니다.
사다리 출력 시
Player이름과Prize내용을 정렬하기 위해OutputView에서padCenter메서드를 사용했습니다.현재 방식은 문자열 길이를 기준으로 직접 공백을 계산하는 방식이라 다소 원시적으로 느껴졌습니다.
출력에서 이런 정렬 책임을 View가 직접 가져도 괜찮은지, 또는 더 좋은 출력 설계 방식이 있는지 궁금합니다.
아직 컨트롤러 테스트는 작성하지 못했습니다.
도메인 테스트는 어느 정도 작성했지만, 입력과 출력이 함께 얽혀 있는 컨트롤러 테스트는 어떻게 접근해야 할지 잘 모르겠습니다.
컨트롤러 테스트를 작성할 때의 팁과, 리뷰어님은 보통 테스트 범위를 어디까지 잡으시는지 궁금합니다.