[4,5단계-사다리] 이지윤 미션 제출합니다. #73
Conversation
- 입력받은 플레이어의 결과와 전체 결과를 볼 수 있게 수정하였습니다. - 전체 결과를 출력하기 전까지 확인하고 싶은 플레이어의 결과를 계속 확인할 수 있게 하였습니다.
|
지윤님 마지막 사다리 미션 고생 많았습니다! |
| @@ -9,14 +9,26 @@ public final class InputView { | |||
| private InputView() { | |||
| } | |||
|
|
|||
| public static String inputLadderWidth() { | |||
| System.out.println("사다리의 넓이는 몇 인가요?"); | |||
| public static String inputPlayerNames() { | |||
There was a problem hiding this comment.
정적 메소드를 사용하는 경우가 보통 출력문같은 단순 기능만 나타낼 때 사용하시는 건가요??
There was a problem hiding this comment.
음, 단순 출력뿐 아니라 정적 메서드는 인스턴스 상태에 의존하지 않는 유틸리티성 클래스에서도 자주 사용해요.
InputView나 OutputView에서는 메서드가 특정 객체의 상태를 사용하지 않고 독립적으로 동작하기 때문에 정적 메서드로 구현했어요.
물론 선택적인 부분인데, 객체의 책임과 무관한 보조 기능이거나 재사용 가능한 공통 기능이라면 정적 메서드로 분리하는 것도 하나의 기준이 될 수 있다고 생각합니다!
| private final List<LadderResult> ladderResults; | ||
| private final Map<String, LadderResult> ladderResultCache; |
There was a problem hiding this comment.
같은 정보를 저장하는것 같은데요! 두가지를 나눈 이유가 있을까요?
Cache는 어떤 역할을 하나요?
There was a problem hiding this comment.
역할을 분리해서 사용하기 위해서 두 자료 구조를 사용해봤어요.
List는 데이터를 입력 순서대로 저장하고 전체를 순회하거나 출력할 때 사용됩니다.Map은 특정 이름으로 빠르게 조회하기 위해 사용했습니다.
→List를 매번 순회하지 않고 바로 접근할 수 있어서, 조회 성능이 더 좋아진다고 판단했습니다!
같은 데이터를 담고 있더라도 저장과 조회 책임을 분리해서 각각의 장점을 활용한 구조라고 생각했습니다.
혹시 과도한 책임 분리일까요?
| public record LadderResult( | ||
| String player, | ||
| String result | ||
| ) { | ||
| } |
There was a problem hiding this comment.
Player, Result 객체를 가지지 않고 String으로 필드를 둔 이유가 있을까요?
There was a problem hiding this comment.
처음엔 LadderResultBoard.of()에서 조립을 하기 때문에 LadderResult가 Player, Result 객체를 직접 들고 있어도 괜찮지 않을까 고민했어요.
그런데 로직을 정리하다 보니 LadderResult는 도메인 행위 없이 최종 결과를 표현하기 위한 역할이라서 굳이 도메인 객체를 직접 들고 있을 필요가 있을까? 하고 생각이 들었습니다.
그래서 도메인 의존성을 줄이고 필요한 데이터만 전달하는 걸 고려해서 String 필드로 구성했어요.
혹시 더 나은 구조가 있을까요?
|
4,5단계까지 오느라 정말 고생 많으셨어요! 마지막까지 화이팅 입니다~~~ 😊 |
| import java.util.List; | ||
| import java.util.stream.Stream; | ||
|
|
||
| public record RequestLadderGame( |
There was a problem hiding this comment.
@Choi-JJunho
RequestLadderGame 하나에 모든 입력값을 한 번에 받고 있는데 이 부분에 대해서는 어떻게 생각하시는 지 궁금합니다!
안녕하세요 주노 🍀
사다리 미션 정말 어렵네요 🥺 마지막까지 리뷰 잘 부탁드립니다 !
🤔 고민한 부분
DTO를 어떻게 구성해야 할지
처음엔 이름, 실행 결과, 사다리 높이 등을 각각 다른 DTO로 받아보려 했어요.
그런데 그렇게 하다 보니 입력값 검증(빈 값 등) 로직이 여러 곳에 흩어져 중복되고 컨트롤러에서 조합해 도메인을 생성하는 흐름도 복잡하고 책임이 분산되는 느낌이었어요.
그래서 지금은
RequestLadderGame하나에 모든 입력값을 한 번에 받고, 이 DTO 내부에서 필요한 도메인 객체들을 생성하는 방식으로 구현했어요.입력 관련 책임이 한 곳으로 모이고 흐름이 단순해졌지만, 반대로
입력 단위를 나누는 게 더 유연한 구조일 수도 있지 않을까?하는 생각도 여전히 들더라고요.재입력 로직을 어떻게 구성할지
"결과를 보고 싶은 사람"을 입력받는 과정에서 잘못된 이름을 입력하면 다시 재입력받아야 했는데,
while 문을 사용하면 indent가 2 이상이 되어버리더라구요.try-catch도 고려했지만, 책임을 명확하게 분리하면서 재사용도 가능한 구조로 만들고 싶어 고민하다가Supplier와Function를 받아 함수형 재귀로 구현해봤습니다!🙋🏻♀️ 궁금한 부분