Skip to content

[그리디] 강대현 사다리 미션 1~5단계 제출합니다.#91

Open
Kdahyn wants to merge 17 commits intonext-step:kdahynfrom
Kdahyn:main
Open

[그리디] 강대현 사다리 미션 1~5단계 제출합니다.#91
Kdahyn wants to merge 17 commits intonext-step:kdahynfrom
Kdahyn:main

Conversation

@Kdahyn
Copy link
Copy Markdown

@Kdahyn Kdahyn commented Apr 27, 2026

🙋‍♂️ 인사

안녕하세요, 해윤님😊 백엔드 4기 강대현입니다. 잘 부탁드립니다!

🚗 구현 내용

1, 2단계

  • 랜덤으로 사다리를 생성하도록 구현했습니다.
  • 참여자 수와 입력받은 높이를 기준으로 사다리를 생성하도록 구현했습니다.

3, 4, 5단계

  • 사다리의 시작 지점과 도착 지점을 함께 출력하도록 구현했습니다.
  • 개인별 실행 결과와 전체 실행 결과를 조회할 수 있도록 구현했습니다.
  • 리팩터링을 진행했습니다.

🤔 고민한 내용

  • printResult에서 컨트롤러의 책임 범위가 어디까지인지 고민했습니다. 현재는 컨트롤러가 View와 DTO를 연결하고, 사용자가 입력한
    all 명령을 해석하는 책임까지 가지도록 구현했습니다.
  • 사다리의 연결 정보를 별도의 Connection 클래스로 분리할지 고민했지만, 현재는 ConnectionGenerator를 통해 연결 여부를
    생성하는 방식으로 구현했습니다.
  • PrizeResult 목록을 PrizeResults라는 일급 컬렉션으로 감싸서, 컨트롤러에서 직접 결과 목록을 다루지 않도록 했습니다.
  • 테스트에서 랜덤 요소를 제거하기 위해 TestConnectionGenerator를 만들었습니다. 미리 정해 둔 연결 값을 순서대로 반환하도록 하여
    예측 가능한 사다리를 생성할 수 있게 했습니다.

❓ 질문사항

  1. printResult를 작성하는 과정에서 들여쓰기 깊이를 1 이하로 유지하기 위해 메서드를 분리했습니다.

    private void printResult(PrizeResults prizeResults) {
        while (retryUntilValid(() -> printResultByName(prizeResults))) {
        }
    }

    그런데 while 하나만 감싸는 메서드가 꼭 필요한지 고민이 되었습니다.
    또한 retryUntilValid 내부에는 whiletry-catch가 함께 있어 들여쓰기 깊이가 생기는데, 이런 공통 예외 처리 메서드까지
    동일한 기준으로 더 분리해야 하는지도 궁금합니다.

  2. 객체 생성을 생성자보다 정적 팩터리 메서드를 통해 처리하려고 했습니다.
    그래서 가능하면 생성자는 private으로 두고, 정적 팩터리 메서드에서 검증이 완료된 객체를 생성하는 방향으로 구현했습니다.

    다만 PlayersLadderGame에서 사다리를 탄 이후의 플레이어 목록을 다시 만들기 위해 생성자를 public으로 두었습니다.
    이 경우 다른 곳에서 의도한 정적 팩터리 메서드 대신 생성자를 직접 사용할 가능성이 생긴다고 생각했습니다.
    이런 경우에도 생성자를 열어두는 것이 괜찮은지, 아니면 별도의 정적 팩터리 메서드를 추가하는 편이 더 좋은지 궁금합니다.

  3. Row를 생성할 때 true 다음에는 자동으로 false를 추가하여, 가로선이 연속으로 생성되지 않도록 구현했습니다.

    현재 방식은 규칙을 만족하기는 하지만, 생성 과정에서 값을 건너뛰거나 추가하는 방식이라 조금 어색하게 느껴졌습니다.
    가로선이 연속되지 않도록 보장하는 더 자연스러운 설계나 구현 방식이 있을지 궁금합니다.

  4. PrizeResult 목록을 일급 컬렉션인 PrizeResults로 만들고 dto 패키지에 위치시켰습니다.

    그런데 PrizeResults가 단순히 데이터를 전달하는 역할뿐 아니라, 이름으로 결과를 찾는 findByName 같은 조회 책임도
    가지고 있습니다.
    이 정도의 책임을 가진 객체를 DTO로 보아도 괜찮은지, 아니면 도메인 또는 다른 패키지로 분리하는 것이 더 적절한지 궁금합니다.

  5. 사다리 출력 시 Player 이름과 Prize 내용을 정렬하기 위해 OutputView에서 padCenter 메서드를 사용했습니다.

    현재 방식은 문자열 길이를 기준으로 직접 공백을 계산하는 방식이라 다소 원시적으로 느껴졌습니다.
    출력에서 이런 정렬 책임을 View가 직접 가져도 괜찮은지, 또는 더 좋은 출력 설계 방식이 있는지 궁금합니다.

  6. 아직 컨트롤러 테스트는 작성하지 못했습니다.

    도메인 테스트는 어느 정도 작성했지만, 입력과 출력이 함께 얽혀 있는 컨트롤러 테스트는 어떻게 접근해야 할지 잘 모르겠습니다.
    컨트롤러 테스트를 작성할 때의 팁과, 리뷰어님은 보통 테스트 범위를 어디까지 잡으시는지 궁금합니다.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant