[🚀 사이클2 - 미션 (기물 확장 + DB 적용)] 루디 미션 제출합니다.

[Seonwu-K]

체크 리스트

• 미션의 필수 요구사항을 모두 구현했나요?
• Gradle test를 실행했을 때, 모든 테스트가 정상적으로 통과했나요?
• 애플리케이션이 정상적으로 실행되나요?

어떤 부분에 집중하여 리뷰해야 할까요?

안녕하세요 제나, 이번에도 비교적 늦은 시간에 요청을 올리게 된 지각생 루디입니다 🥲

이번 PR에서는 궁성 특수 규칙, 점수 계산, 게임 승패판정(왕이 잡혔는지)와 진행 도중 종료 시 게임 재개(DB 활용) 기능 등을 구현했습니다.

구현을 적절하게 했는지,DB 도입, 설계, 사용 방식 등이 적절했는지도 중요하지만, 아래 설계 판단에 대해서 특히 피드백 받고 싶습니다.

1. Tell, Don’t Ask 적용 수준이 적절한지

이번 장기 미션 동안 객체 지향 설계 원칙 중에서도 가장 의식하면서 적용하고자 했던 부분이 이 TDA라고 생각합니다.

사이클1~2 내내 이를 최대한 반영해보고자 하였는데 그 과정에서 이 '묻지 말고 직접 시킨다'는 항상 정답이 될 수 있는 방식은 아님을 느끼게 된 것 같습니다.

그렇다면 어떤 상황에서 어디까지 TDA를 의식하고 코드를 작성해야 하는가에 대한 자신만의 기준을 세워야 할 것 같은데, 아직은 경험이 부족해서 헷갈리는 상황에 자주 처하게 되는 것 같아요. 제나는 이 규칙을 적용하는 상황에 어떤 기준을 가지고 계신지 궁금합니다 .

현재 저의 코드에도 TDA를 시도한 부분과, 선택적으로 다른 우선순위(추상화, 해당 객체의 책임이 적절하다는 판단 등)를 고려하여 TDA 대신 직접 값을 꺼내 조립하기도 하는 상황이 섞여 있는 것 같습니다. 이 부분에 대해서 판단이 적절했을지 궁금합니다. (이 부분이 어떤 코드인지는 해당 코드에 코멘트로 남겨두겠습니다.)

2. 객체 수와 책임 분리가 과한지

이번 PR과 이전 사이클까지 포함해 Game, GameStatus, FormationType, GameRepository, H2GameRepository, Palace, PalaceRouteGenerator, 점수 정책 객체 등 의미를 분리한 객체들이 계속 늘어났습니다.

자신의 역할에만 집중할 수 있는 코드를 만들기 위해 책임이 섞인다고 느껴지는 부분이 있거나, 단순 값 객체라도 의미를 가지는 단위가 있다고 판단 되면 최대한 묶어서 표현하고자 했는데 완성 시점에서 돌아보니 너무 많은 객체를 만들어 낸 것은 아닌가 의문이 들었습니다.

• 지금의 분리가 도메인 의미를 잘 드러내는 수준인지
• 아니면 작은 책임까지 너무 잘게 쪼개서 오히려 읽기 어려워졌는지
• 값 객체/엔티티/정책 객체를 만드는 기준이 현재 코드에서 일관되게 적용되고 있는지
  가 궁금합니다.

3. 응집도와 결합도 관점에서 현재 구조가 괜찮은지

구현 과정에서는 우선 기능을 완성하는 데 집중했고, 그 다음 단계에서 구조를 돌아보며 응집도와 결합도를 점검하고 있습니다. 처음부터 OCP를 의식하고 설계한 것은 아니지만, 이번 미션에서 요구하는 방향 자체가 결국 “기능 추가나 규칙 변경 시 기존 코드를 크게 흔들지 않는 구조”를 강조한다는 점에서 OCP에 대한 내용을 학습하고 있다고 느꼈습니다.

그래서 현재 코드가 아래 관점에서 어느 정도 적절한지 피드백을 받고 싶습니다.

• 각 객체가 자신의 경계 안에서 책임을 비교적 잘 지키고 있는지
• 객체들이 알아야 할 것만 알고 협력하는 구조인지, 혹은 아직 결합이 강한 부분이 남아 있는지
• 기능 수정이나 확장 시 영향 범위를 줄일 수 있는 구조라고 볼 수 있는지
• OCP를 엄격하게 지킨 수준은 아니더라도, 이번 코드가 그 방향으로 어느 정도 가고 있는지
• 반대로 아직도 책임이 과하거나 변경에 취약한 지점이 있다면 어디를 가장 먼저 개선해야 하는지

[Seonwu-K]

점수 규칙은 계산과 정책을 분리했지만, 여전히 Board에서 목록을 꺼내고 PieceType을 기준으로 점수를 계산합니다. 이 정도 분리는 적절한지, 더 객체에게 메시지를 보내는 쪽이 나을지 궁금합니다.

[Seonwu-K]

궁성 규칙은 Piece가 PalaceRouteGenerator를 가지고 협력하도록 구현해봤습니다.
이 판단은 적절한지 궁금합니다.

[yenawee]

궁성 이동도 결국 기물의 이동 규칙이니 Piece 에 있는 것이 적절하다고 생각합니다.

하지만 지금 Piece가 "어떤 기물은 전략으로, 어떤 기물은 Palace로"를 직접 판단하는 조건 분기의 책임까지 짊어지고 있습니다.

KING/GUARD도 자신만의 MoveStrategy를 갖도록 하는 건 어떨까요? Optional을 필드로 사용하는 것은 안티패턴이라, 이부분도 개선이 될 것. ㅏㅌ. 네ㅛ.

[Seonwu-K]

게임 흐름 전체에서는 Game을 도입해 루프 제어와 상태 변경은 메시지로 옮겼지만, 선택 가능한 기물/경로 조회와 검증은 여전히 GameRunner가 직접 조합하고 있습니다.
물론 도메인 규칙을 아예 모르는 상태로 엄격히 계층간 흐름만 조율하는 '컨트롤러'와는 달리 GameRunner는 도메인 규칙에 대한 책임을 가지면서 흐름 처리를 돕는 역할로서 설계하였으나, 현재의 로직은 러너가 충분히 알아도 되는 만큼 알고 있는 것이 맞는지 궁금합니다.

[yenawee]

선택 가능한 기물/경로 조회는 "사용자에게 뭘 보여주고 뭘 입력받을지"에 대한 판단이라 Runner가 알아도 된다고 생각합니다.

하지만 현재 playTurn() 에서는,

1. 왕이 잡히면 게임이 끝난다
2. 왕이 안 잡혔으면 턴을 넘긴다

"게임이 어떤 조건에서 어떤 상태로 전이하는가" 라는 핵심 도메인 규칙을 알고 있습니다.
다른 요구사항이 추가된다면 게임 러너를 수정해야 할 것으로 보입니다.

"장기의 규칙"은 Game 이 알게 하도록 개선해봅시다.

[yenawee]

FormationType이 도메인 패키지에 있지만 전략 패키지에 의존하고 있습니다.

도메인 → 전략 방향의 의존이 발생합니다. 보통 전략이 도메인에 의존하는 것이 자연스러운 방향입니다.

[yenawee]

Board.move에서 잡힌 기물을 Map에서 제거하지 않고 있습니다.
pieces.put(destination, piece)가 기존 값을 덮어쓰므로 결과적으로 잡힌 기물은 제거됩니다. 동작은 맞지만, 잡힌 기물의 제거가 put의 부수효과로 암묵적으로 일어난다는 점이 가독성을 떨어뜨릴 수 있습니다.

[yenawee]

Repository에서 save 후 ID를 주입하는 패턴인데, Game이 자신의 식별자가 나중에 바뀔 수 있는 가변 상태가 됩니다. save 시 새 Game 인스턴스를 반환하는 방식이 더 안전합니다