[🚀 사이클1 - 미션 (보드 초기화 + 기물 이동)] 테리 미션 제출합니다. by Yeji-Kim-Erica · Pull Request #243 · woowacourse/java-janggi

Yeji-Kim-Erica · 2026-03-28T17:52:54Z

💌 인사말

안녕하세요, 초코칩! 리뷰이 테리입니다.
귀중한 시간을 리뷰 참여에 할애해주셔서 감사드립니다.
가감 없이 부족한 부분들에 대해 알려주세요.
최선을 다해 개선하고 공부하겠습니다. 🙇‍♂️

체크 리스트

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

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

고민했던 부분

1. 상태 소유와 책임의 일치: 기물의 위치 정보를 가지는 주인은 누구인가

'기물의 현재 위치(Location)'라는 상태를 Piece 객체가 가져야 할지, 아니면 기물을 관리하는 Board가 가져야 할지 고민했습니다.
현실 세계를 반영하면 기물이 자신의 위치를 아는 것이 자연스러워 보였지만, 만약 Piece가 위치를 가진다면 Board가 기물을 이동시킬 때마다 getter/setter를 사용해 상태를 묻고 변경해야 하므로 캡슐화를 저해한다고 판단했습니다.
따라서 상태를 직접 조작하고 활용하는 주체인 Board가 위치 정보를 관리하도록 설계했습니다.
"현실 세계의 모방"보다 "책임 주체와 상태 소유의 일치"를 우선시해야 한다는 기준을 세우고 설계해봤는데, 이 설계 방향이 객체지향적으로 적절한지 초코칩의 의견이 궁금합니다!

2. 기물 동적 생성 시 리플렉션 vs 함수형 인터페이스

BoardAssembler에서 각 기물 객체를 생성할 때, 초기에는 리플렉션을 사용하는 것을 고려했습니다.
하지만 페어와 의견을 나누고 정보를 찾아보는 과정에서 리플렉션은 타입 안정성을 저해하고 런타임 에러를 유발할 수 있다는 단점이 있다는 사실을 알게 되었습니다.
이를 해결하기 위해 Java 8의 함수형 인터페이스(Function<Side, Piece>)와 생성자 참조를 활용해 팩토리 로직을 구현했습니다. 이를 통해 DIP를 위반하지 않으면서도 안전하게 동적으로 기물을 생성할 수 있었는데, 더 나은 개선 방향이 있을지 궁금합니다.

3. View와 Domain의 경계 및 흐름 제어

의존성: ApplicationView가 도메인 객체인 ArrangementStrategy 인스턴스를 직접 알고 있는 것이 도메인 경계를 흐린다고 판단했습니다. 따라서 View에는 순수 데이터인 Enum의 원시값이나 String만 넘기도록 구조를 변경했습니다.
흐름 제어: 사용자 입력 재시도 로직의 책임을 어떻게 나눌지 고민했습니다. 결론적으로 View 는 '입력 형식 자체(공백, 숫자 여부 등)'에 대한 예외 발생을 담당하고, Controller(JanggiFlow 클래스)는 view에서 발생시킨 예외와 '도메인 로직 검증(유효한 전략 번호, 보드 이동 가능 여부 등)' 실패에 대한 예외를 잡아서 재시도를 담당하도록 역할을 설정했습니다. 이 계층 간의 책임 분리가 적절하게 이루어졌는지 중점적으로 살펴봐주시면 감사하겠습니다.

아직까지 도메인과 입출력의 연결 다리인 Controller가 어디까지 책임을 져야 하는지에 대한 기준이 모호한 상태인데 지금의 역할 책임 분리가 적절한지도 궁금합니다!

- 입력 검증 및 예외 처리 - 입력이 정수가 아닌 경우 - 입력값에 매핑되는 전략 패턴이 존재하지 않는 경우 - 전략 패턴 식별 라벨 추가

- 도메인 패키지 분리

- isSameSide 메서드의 파라미터 타입을 Side 에서 Piece로 수정

- BoardAssembler에게 전달받은 2차원 배열 정보를 조합해 Board 객체를 생성함 - Board의 Map<Location, Piece> 내용을 2차원 List 형태로 반환함

- 장기 기물에 기물명 필드를 추가함 - 팀(Side)의 팀명 필드를 추가함 - 각 팀의 장기 초기화 전략을 선택할 수 있도록 흐름을 수정함

양 팀의 기물명을 모두 표현할 수 있도록 클래스명을 Jol 에서 JolByeong으로 변경함

- 기물 이동 규칙을 주요 게임 규칙으로 추가

- readInteger를 readInt로 변경: Integer는 참조 타입 클래스명으로, input 값으로 null이 들어올 수 있다는 의미를 내포할 수 있으므로 메서드의 실제 반환 타입인 int로 수정함

- 이동할 기물의 위치를 입력받는 기능을 추가함 - 기물을 이동시킬 위치를 입력받는 기능을 추가함

- 프로덕션 클래스 패키지 구조와 동일하도록 테스트 클래스의 패키지 경로 수정

- 기물의 이동 방향에 따라 좌표에 더해줄 값을 알려주는 Direction 클래스 추가 - 기물이 특정 위치로 이동하기 위해 지나쳐야 하는 경로의 Location 목록을 알려주는 Route 클래스 추가 - Piece 추상 클래스에 calculateRoute 추상 메서드 추가 - 졸병 기물의 이동 규칙을 적용한 기물 이동 기능 추가

- 마와 상은 팀에 관계 없이 경로 계산이 가능하므로 테스트명에서 WhenTeamHan, WhenTeamCho 를 제거함

- 이동 경로 계산 규칙이 중복되는 기물의 계산 로직을 RouteRule 인터페이스로 추상화함 - 궁과 사는 궁성이라는 영역 제한 규칙을 동일하게 가지므로 GungSeongRouteRule 이라는 구현 클래스를 사용하도록 함

- 기물 이동 규칙을 검증하는 방법은 두가지임: 이동 가능한 경로, 경로 도중에 장애물이 있는지 여부 - 각각 검증을 위한 인터페이스를 개별적으로 만들면서 '규칙'의 의미가 여러 클래스로 흩어지게 되었므로, 각 클래스가 검증하는 대상에 집중한 이름으로 네이밍 변경

- direction으로 되어있던 규칙 패키지명을 rule로 변경 - 경로에 관한 규칙을 지닌 인터페이스 및 클래스들을 하위 패키지인 route 패키지로 이동

- 포를 제외한 기물의 이동 경로에 다른 기물이 존재하는지 확인하고 예외를 발생시키도록 함 - 도착지에 같은 팀의 기물이 존재할 경우 예외를 발생시키도록 함 - 전체 코드 포맷팅을 정렬함

- 테스트용 구현 클래스들을 support 패키지에 모으고 클래스명을 Test로 시작하도록 네이밍 컨벤션 통일

- 테스트용 전략 클래스 추가

- 기물 이동의 출발 좌표와 도착 좌표를 검증하는 validate 메서드들의 구조를 변경

- 상태를 가지지 않는 불변 객체이므로, 불필요한 객체 생성을 막기 위해 싱글톤으로 변경

- 상태를 가지지 않는 불변 객체이므로, 불필요한 객체 생성을 막기 위해 싱글톤으로 변경 - BoardAssemblerTest가 프로덕션 전략에 의존하지 않도록, 테스트 전용 전략 객체를 주입하여 테스트 결합도를 낮춤

- 상태를 가지지 않는 불변 객체이므로, 불필요한 객체 생성을 막기 위해 싱글톤으로 변경 - Po 클래스의 RouteProvider 상수가 GungSeongRouteProvider의 인스턴스를 할당받던 것을 Po의 직선 이동 규칙에 맞도록 StraightRouteProvider의 인스턴스를 할당받도록 함으로써 버그 수정

- 기물의 종류를 표현하는 PieceType Enum 클래스 구현 - 각 기물마다 구현하던 Piece의 isEmpty() 추상 메서드를 일반 메서드로 변경 - isEmpty() 호출 시 PieceType이 EMPTY인지 확인하도록 로직을 작성해 응집도를 높임

- RouteProvider: 중복되던 길 찾기 필터링 로직을 static 메서드(findValidPath)로 추출해 일원화하고 다형성 구조 개선 - Piece: 기물 내부의 불필요한 예외 번역을 걷어내고, 에러 발생 시 PieceType을 전달해 정확한 메시지를 반환하도록 수정 - Board: 출발지 정보를 활용해 제자리 이동 방지 로직을 추가하고, 불필요한 래퍼 메서드를 제거해 응집도를 높임 - 의도를 명확히 드러내도록 각종 클래스의 메서드명 및 변수명 변경

- ArrangementStrategy: 기본 기물(차, 포, 궁 등)을 배치하는 공통 로직을 부모의 public 메서드(place)로 묶고, BoardAssembler에 위치해있던 기물 생성 내부 클래스(DefaultPieceFactory)를 가져옴 - BoardAssembler: 기물의 구체적인 위치 지식을 제거하고, 각 진영의 전략 객체에 보드판 조립을 위임하도록 책임 축소 - 하위 전략 클래스는 placeVariablePieces()만 구현해 변동 기물(마, 상) 배치만 담당하도록 구조 개선 - 변경된 책임에 맞게 BoardAssemblerTest는 빈칸 채우기만 검증하도록 하고, ArrangementStrategyTest에 기본 기물 배치 검증 로직 추가

- JanggiFlow: 잘못된 입력(전략, 기물 선택, 이동 좌표)으로 예외 발생 시, 에러 메시지를 출력하고 정상 입력될 때까지 다시 요청하는 로직 수정 및 추가 - RouteProvider: 기물 이동 경로 위반 에러 메시지 수정 - ConsoleWriter: 에러 메시지 출력 후, 보드판 출력 전 개행을 추가해 콘솔 화면 가독성 개선

- Application, JanggiFlow: 전략 객체 리스트를 외부에서 주입받도록 변경해 OCP 준수 - JanggiFlow, ApplicationView: 컨트롤러에서 도메인 객체를 순수 데이터로 변환 후 뷰에 전달하도록 수정해 강한 결합도 해소 - JanggiFlow: 뷰와 컨트롤러에 분산되어있던 재입력 로직을 컨트롤러에서 모두 관리하도록 흐름 제어 책임 일원화

Chocochip101

안녕하세요, 테리 반갑습니다! 미션 리뷰어로 함께하게 된 초코칩입니다 🍪
미션 잘 구현해주셨네요 👍
코멘트 남겨두었으니 확인해보시고 재요청주세요!

README.md

Chocochip101 · 2026-03-28T21:46:41Z

src/main/java/janggi/controller/JanggiFlow.java

+import java.util.List;
+import java.util.Map;
+
+public class JanggiFlow {


Flow는 어떤 것을 의미하나요?

왜 controller 패키지 안에 있나요? controller는 무엇을 의미하나요?

클래스의 역할과 네이밍에 대해 본질적인 고민을 던져주셔서 감사합니다!
두 질문이 결국 '이 클래스의 정체성'을 향하고 있어서 함께 묶어서 답변을 남겨봅니다.

1. Controller는 무엇을 의미하고, 왜 이 패키지에 있나요?

제가 생각한 Controller는 Model과 View 사이를 연결해주는 중재자입니다. Board, Piece 등의 도메인은 콘솔 입력/출력을 전혀 모른 채 순수 장기 규칙만 처리하고, View는 도메인 객체를 직접 조작하지 않고 데이터만 뿌리도록 결합도를 낮추는 것이 목표였습니다.
현재 이 클래스는 View를 통해 사용자의 입력을 받고, 도메인 메서드를 호출해 명령을 내리며, 다시 도메인의 상태를 View로 전달하는 다리 역할을 수행하고 있기 때문에 controller 패키지에 배치했습니다.

2. Flow는 어떤 것을 의미하나요?

'Flow'라는 이름은 이 컨트롤러가 장기 게임의 전체적인 진행 흐름을 제어한다는 의미로 지었습니다.
(배치 전략 묻기 -> 초기 세팅 -> 승패가 날 때까지 턴을 반복하며 기물 이동하기)

다만 질문을 받고 다시 생각해 보니, 'Flow'라는 단어는 상태나 역할보다는 '현상 자체'에 가까운 추상적인 단어라,
처음 코드를 보는 사람에게 이 클래스가 MVC의 컨트롤러라는 점이 직관적으로 와닿지 않을 수도 있겠다는 생각이 들었습니다.
이 클래스의 중재자 역할이 더 명확히 드러나도록 JanggiController 혹은 게임의 전체 흐름을 통제한다는 의미의 GameController로 이름을 변경하는 것을 더 권장하시는지 초코칩의 의견이 궁금합니다! 🙇‍♂️

src/main/java/janggi/domain/board/Board.java

src/main/java/janggi/controller/JanggiFlow.java

src/main/java/janggi/strategy/BoardAssembler.java

src/main/java/janggi/controller/JanggiFlow.java

src/main/java/janggi/domain/board/Board.java

src/main/java/janggi/view/ConsoleWriter.java

README.md

- ApplicationView의 입출력 메서드 접두사를 의도가 더 명확한 `promptFor`, `show`로 변경해 가독성 향상 - `convertBoardStatus` 내부의 `boradIn2D` 변수명 오타를 `boardIn2D`로 수정 - `repeatAskLocationToMoveUntilSuccess` 메서드에서 사용하지 않는 불필요한 매개변수(`turnSide`) 제거

- 기존 로직에서 HAN이 아닐 경우 무조건 HAN을 반영해, NONE 등 유효하지 않은 상태에서 호출될 시 발생할 수 있는 잠재적 버그 차단 - CHO 상태일 경우에만 명시적으로 HAN을 반환하도록 조건 개선 - 유효하지 않은 진영에서 상태 반전 시도 시 UnsupportedOperationException을 던지도록 예외 처리 추가

- 최상위 ArrangementStrategy를 인터페이스로 분리해 역할 명확화 - 마/상 배치를 제외한 고정 기물 배치를 담당하는 MaSangArrangementTemplate 추상 클래스 도입: 기물 초기화시 발생하던 덮어쓰기 문제 해결 및 OCP 확보 - 도메인이 UI 데이터를 들고 있던 StrategyLabel을 삭제하고, 입력 번호와 전략 객체를 매핑하는 ArrangementStrategyResolver 도입 - JanggiFlow 내부의 전략 객체 매핑 및 캐싱 로직을 Resolver로 위임해 컨트롤러 무상태 유지 및 책임 분리 - 하위 전략 구현체들의 네이밍을 명확하게 변경 (ex. MaSangMaSang -> MaSangMaSangStrategy)

@DisplayName

▶ Piece & Movement 구조 개편 - Piece를 인터페이스로 변경하고, 구현체를 ActivePiece와 EmptyPiece로 일원화 - 기존 개별 기물 클래스(Cha, Ma, Sang 등)를 순수 이동 전략인 Movement 구현체(ChaMovement, MaMovement 등)로 분리 - PieceFactory를 도입해 PieceType과 Movement 매핑 및 객체 조립 책임 캡슐화 - Ma, Sang의 경로(possibleRoute) static 초기화 시점 꼬임으로 인한 null 할당 이슈를 방지하기 위해 생성자 내부 초기화로 수정 ▶ RouteProvider & Collision 검증 로직 개선 - RouteProvider가 경로 탐색 실패 시 예외 대신 Optional.empty()를 반환하도록 변경해 실제 예외 발생 지점을 Piece로 설정. 이에 따라 예외 메시지에서 기물 이름을 표시하기 위해 PieceType을 넘겨주던 부분을 제거할 수 있었음. - CollisionDetector가 Piece 객체 대신 Side 정보만으로 충돌을 판별하도록 결합도 완화 ▶ 초기 기물 배치 구조 개선 - ArrangementStrategyResolver를 역할에 맞게 ArrangementOption으로 이름 변경 및 직관적인 메서드명 적용 - Strategy 구현체가 생성자로 진영을 받아와 필드에 저장하고 로직에 적용하도록 구조를 개선해 BoardAssembler가 하드코딩된 진영을 내부 로직에서 사용하는 대신 List<ArrangementStrategy>를 유연하게 받을 수 있게 함 ▶ 테스트 코드 현행화 및 가독성 향상 - 변경된 Optional 반환 타입에 맞춰 hasValue(), isEmpty() 기반으로 검증 로직 전면 수정 - 테스트 메서드명 및 @DisplayName을 구현 상세(파라미터 등)가 아닌 행위와 도메인 용어 중심으로 개선

- ConsoleWriter가 RuntimeException 객체 대신 String 타입의 에러 메시지를 인자로 받도록 수정 - Controller에서 예외를 캐치해 메시지만 추출한 뒤 View에 전달하도록 흐름 변경 - View가 예외 객체의 존재를 알 필요 없이 '출력'이라는 본연의 역할에만 집중하도록 결합도 완화

- Board 클래스에서 열의 길이를 구하기 위해 사용된 하드코딩된 숫자 0을 FIRST_ROW_INDEX 상수로 분리해 매직 넘버 제거 및 가독성 향상

- 잘못된 입력이 반복될 경우 Call Stack이 쌓여 StackOverflowError가 발생하는 위험을 방지하기 위해 재귀 대신 while 반복문 적용 - 여러 입력 로직에서 재시도 로직이 중복되는 것을 막기 위해, Supplier를 활용한 공통 retry() 메서드를 구현해 가독성과 재사용성 향상

- BoardAssembler의 초기화 순서를 '빈칸 null 체크' 방식에서 'EmptyPiece 선배치 후 덮어쓰기' 방식으로 변경

- Board 초기화 시 행 단위 매핑 로직을 메서드로 추출해 indent depth를 1로 감소 - Board 출력을 위한 to2DArray() 내부의 2중 for문 역시 별도 메서드로 추출해 indent depth를 1로 감소

- 사용자가 기물의 위치를 쉽게 파악하고 입력할 수 있도록 ConsoleWriter에 행/열 좌표 출력 로직 추가 - 한글 기물과 숫자 간의 콘솔 출력 너비(시각적 크기) 차이로 인한 정렬 깨짐 문제를 해결하기 위해, 상단 열 번호에 전각 숫자를 도입해 완벽한 격자 정렬 구현 - 사용자가 확인하고 입력하는 좌표(1~10, 1~9)를 내부 2차원 배열용 좌표로 변환하는 책임을 도메인(Location)에 캡슐화 - Location 팩토리 메서드 역할 변경에 따라, 기존 테스트 코드들의 Location 생성 방식을 일괄 수정

Chocochip101

안녕하세요, 테리!
잘 반영해주셨네요 👍🏻
몇 개의 커맨트 남겼으니 확인해주세요.

Chocochip101 · 2026-04-03T19:43:14Z

src/main/java/janggi/domain/Location.java

+
+import java.util.List;
+
+public record Location(int x, int y) {


일반적으로 x는 열, y는 행을 의미하지 않나요?(알고리즘 풀 때 그렇게 썼던 기억이 있네요 🤔)
여기는 반대로 쓰이는 것 같네요. 아니면 row, col로 더 명시적으로 표현하는 것은 어떤가요?

Chocochip101 · 2026-04-03T19:52:36Z

src/main/java/janggi/view/ConsoleWriter.java

+public class ConsoleWriter implements Output {
+
+    private static final String BLANK = "   ";
+    private static final List<String> FULL_WIDTH_NUMBERS =


상수화 👍🏻
BoardAssembler의 DEFAULT_ROWS, DEFAULT_COLS가 바뀌면 여기도

Chocochip101 · 2026-04-03T19:52:55Z

src/main/java/janggi/domain/Side.java

+
+    HAN("한"),
+    CHO("초"),
+    NONE("없음");


NONE이 현재 쓰이나요?

Chocochip101 · 2026-04-03T19:54:09Z

src/main/java/janggi/domain/Side.java

+
+    HAN("한"),
+    CHO("초"),
+    NONE("없음");


아래와 같이 쓰면, 다음 사람이 다른 Enum을 추가할때 변경사항에 안 잡히게 됩니다 :)

Suggested change

NONE("없음");

NONE("없음"),

;

Chocochip101 · 2026-04-03T20:03:27Z

src/main/java/janggi/view/ConsoleReader.java

+                }).toList();
+        return List.copyOf(integers);


.toList()는 이미 불변 리스트를 반환해서, copyOf가 불필요해보이네요.

Chocochip101 · 2026-04-03T20:08:14Z

src/test/java/janggi/domain/rule/route/RouteTest.java

+class RouteTest {
+
+    @Test
+    @DisplayName("현재 위치에서 주어진 Direction 들을 적용했을 때 지나는 경로를 반환한다.")


이동 불가 경로로 이동 시도(예를들어 차가 대각선 이동 시도, 경로에 기물이 있을 때 등)에 대한 실패 테스트가 있나요? 👀

Chocochip101 · 2026-04-03T20:22:36Z

src/main/java/janggi/strategy/MaSangArrangementStrategy.java

+        private Piece createPiece(Side side) {
+            if (this == JOLBYEONG) {
+                return FACTORY.createActivePiece(getJolOrByeongBySide(side), side);
+            }
+            return FACTORY.createActivePiece(this.pieceType, side);


DefaultPieceFactory의 Enum으로 Piece를 구분하는데, createPiece에서 분기처리하네요.
그리고 enum의 JOLBYEONG은 PieceType.JOL을 들고 있는데, pieceType 필드를 쓰지 않네요.

아래처럼 처리해보는건 어떤가요?

JOLBYEONG(3, List.of(0, 2, 4, 6, 8), side -> side == Side.HAN ? PieceType.BYEONG : PieceType.JOL);

Chocochip101 · 2026-04-03T20:31:34Z

src/main/java/janggi/domain/Side.java

+        this.name = name;
+    }
+
+    public Side switchSide() {


enum이 자신의 다음 상태를 if/if로 판단하고 있네요.
상수가 자신의 다음 상태를 직접 알게 할 수 있지 않을까요?

Chocochip101 · 2026-04-03T20:36:38Z

src/main/java/janggi/domain/piece/ActivePiece.java

+    protected final PieceType pieceType;
+    protected final Side side;


private으로 변경해도 되겠네요.

Yeji-Kim-Erica added 30 commits March 25, 2026 15:18

docs(README): 사이클 1: 1단계 구현 기능 목록 추가

0ceec3c

feat: 장기판 초기화 전략 번호 입력 기능 추가

7f73e77

- 입력 검증 및 예외 처리 - 입력이 정수가 아닌 경우 - 입력값에 매핑되는 전략 패턴이 존재하지 않는 경우 - 전략 패턴 식별 라벨 추가

feat: 장기판 초기 배치 기능 추가

0be33b8

- 도메인 패키지 분리

refactor(BoardAssembler): 생성 시에 전략을 주입받도록 변경

e8d6b4c

feat(BoardAssembler): 비어있는 위치를 EmptyPiece 객체로 초기화하는 기능 추가

9c9605d

refactor(Piece): 같은 편을 확인하는 메서드의 파라미터 수정

3f0af3a

- isSameSide 메서드의 파라미터 타입을 Side 에서 Piece로 수정

feat(Board): 장기판 생성 및 반환 기능 추가

381957c

- BoardAssembler에게 전달받은 2차원 배열 정보를 조합해 Board 객체를 생성함 - Board의 Map<Location, Piece> 내용을 2차원 List 형태로 반환함

feat: 장기판 출력 기능 추가

c1c423e

- 장기 기물에 기물명 필드를 추가함 - 팀(Side)의 팀명 필드를 추가함 - 각 팀의 장기 초기화 전략을 선택할 수 있도록 흐름을 수정함

refactor(JolByeong): 클래스명을 포괄적 의미를 갖도록 수정

b750b23

양 팀의 기물명을 모두 표현할 수 있도록 클래스명을 Jol 에서 JolByeong으로 변경함

style: 개행 추가

d699f78

docs(README): 사이클 1: 2단계 구현 기능 목록 추가

8f0e517

- 기물 이동 규칙을 주요 게임 규칙으로 추가

refactor: 정수를 읽어오는 메서드명 변경

748f714

- readInteger를 readInt로 변경: Integer는 참조 타입 클래스명으로, input 값으로 null이 들어올 수 있다는 의미를 내포할 수 있으므로 메서드의 실제 반환 타입인 int로 수정함

feat: 기물 이동을 위한 좌표 입력 기능 추가

4060f81

- 이동할 기물의 위치를 입력받는 기능을 추가함 - 기물을 이동시킬 위치를 입력받는 기능을 추가함

refactor: 테스트 클래스 패키지 정리

584b043

- 프로덕션 클래스 패키지 구조와 동일하도록 테스트 클래스의 패키지 경로 수정

feat: 마의 기물 이동 경로 좌표 목록 계산 기능 추가

a9e05d2

feat: 상의 기물 이동 경로 좌표 목록 계산 기능 추가

ac68f60

refactor: 기물 마와 상의 테스트명을 테스트 내용에 맞게 수정

6322b8c

- 마와 상은 팀에 관계 없이 경로 계산이 가능하므로 테스트명에서 WhenTeamHan, WhenTeamCho 를 제거함

feat: 차, 상의 기물 이동 경로 좌표 목록 계산 기능 추가

356b578

refactor: 기물 이동 규칙 관련 패키지명 변경

0441baa

- direction으로 되어있던 규칙 패키지명을 rule로 변경 - 경로에 관한 규칙을 지닌 인터페이스 및 클래스들을 하위 패키지인 route 패키지로 이동

feat: 포 이동 시 장애물 충돌 감지 기능 추가

8e916fd

refactor: 테스트용 구현 클래스 패키지로 정리

6aadc0b

- 테스트용 구현 클래스들을 support 패키지에 모으고 클래스명을 Test로 시작하도록 네이밍 컨벤션 통일

feat(Board): 기물 이동 기능 추가

5800252

- 테스트용 전략 클래스 추가

feat: 이동이 반영된 장기판 상태 출력 기능 추가

b55d7fa

- 기물 이동의 출발 좌표와 도착 좌표를 검증하는 validate 메서드들의 구조를 변경

refactor(EmptyPiece): 빈 기물에 싱글톤 패턴 적용

770eef2

- 상태를 가지지 않는 불변 객체이므로, 불필요한 객체 생성을 막기 위해 싱글톤으로 변경

Yeji-Kim-Erica added 5 commits March 28, 2026 21:58

Chocochip101 requested changes Mar 29, 2026

View reviewed changes

Yeji-Kim-Erica added 10 commits March 31, 2026 12:33

refactor: 2차원 배열 너비 조회를 위한 인덱스 매직 넘버를 상수로 추출

f031242

- Board 클래스에서 열의 길이를 구하기 위해 사용된 하드코딩된 숫자 0을 FIRST_ROW_INDEX 상수로 분리해 매직 넘버 제거 및 가독성 향상

refactor: 2차원 배열 초기화 로직 개선 및 인덴트 감소

bc27b6b

- BoardAssembler의 초기화 순서를 '빈칸 null 체크' 방식에서 'EmptyPiece 선배치 후 덮어쓰기' 방식으로 변경

Chocochip101 requested changes Apr 3, 2026

View reviewed changes


		import java.util.List;

		public record Location(int x, int y) {

		protected final PieceType pieceType;
		protected final Side side;

Conversation

Yeji-Kim-Erica commented Mar 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

💌 인사말

체크 리스트

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

고민했던 부분

1. 상태 소유와 책임의 일치: 기물의 위치 정보를 가지는 주인은 누구인가

2. 기물 동적 생성 시 리플렉션 vs 함수형 인터페이스

3. View와 Domain의 경계 및 흐름 제어

Uh oh!

Chocochip101 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

1. Controller는 무엇을 의미하고, 왜 이 패키지에 있나요?

2. Flow는 어떤 것을 의미하나요?

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Chocochip101 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Yeji-Kim-Erica commented Mar 28, 2026 •

edited

Loading