-
Notifications
You must be signed in to change notification settings - Fork 0
1주차 수요일 그룹 5
kariskan edited this page Jun 28, 2024
·
1 revision
- Piece안에 Position을 관리하는 것에 대해서, Board가 Position을 관리해도 되지 않나?
- 사실 지금 코드도 Board에서만
piece.getPosition()
이런 식으로 관리하고 있어서 Piece의 Position은 없어도 될 것 같다. - 이렇게 하면 Board 상에서 어느정도 if-else가 필요하긴 하지만 지금 move시에 board에서는 piece의 position도 swap하고 있다.
- 아마 Position을 제외하거나, 따로 관리할 듯 하다. Piece 에서도 position이 자리만 차지하지, 거의 사용되지 않음.
- 사실 지금 코드도 Board에서만
- 점수를 구하는 부분도 Board에서 하고 있는데, 요구사항 중에
세로 줄에 2개 이상의 Pawn이 있을 경우, 각 Pawn은 1점이 아닌 0.5점으로 한다
라는게 있어서, 세로 줄을 탐색해야 하는 경우가 있었음.- 이것 때문에 PieceType이 defaultPoint를 가지고 있는데, Board에서 calculatePoint를 할 수 밖에 없었다.
- Rank라는게 체스에서 row를 뜻하는 단어라고 하는데, column을 뜻하는 단어를 사용해서
List<Column>
이런 식으로 해도 괜찮을 것 같다.- 근데 Pawn 세로 점수 하나를 위해서 이걸 하는 것도 맞는지는 모르겠다.
- 외부에서 의존하지 않는 클래스라면 최대한 접근 제어자를 제한하는 것이 좋아 보인다. inner enum을 만드는 것도 마찬가지
-
List<List<Piece>>
와Board -> List<Rank>, Rank -> List<Piece>
로 관리하는 것의 차이- 후자는 board 전체에 대한 행동을 정의하는 클래스와, 각 row가 가지는 행동을 정의하는 클래스로 일급 컬렉션을 나눠서 사용했는데, 솔직히 row에 대한 어떤 행동을 정의하는게 크게 없어서.. 2차원
List
로 해도 될 듯 하다. - 그도 그럴것이 Rank 자체에는 그리 하는 역할이 크지 않음
- 그런데 2차원 List로 관리하면 코드의 indent 또한 줄일 수 있어서 가독성이 좋을 것 같긴 하다.
- 후자는 board 전체에 대한 행동을 정의하는 클래스와, 각 row가 가지는 행동을 정의하는 클래스로 일급 컬렉션을 나눠서 사용했는데, 솔직히 row에 대한 어떤 행동을 정의하는게 크게 없어서.. 2차원
- PieceType 은 Piece 에서만 사용하기 때문에 Piece class 안의 Inner Class 로 생성하는 것이 나을 것 같다.
- 현재 Position class 를 정의하지 않았지만 Position의 validation 담당이나 다른 역할이 쓰일 가능성이 있어 Position class 를 정의하는 것도 나쁘지 않아 보인다.
- 테스트 할 때 @Parameterized 를 사용해 보는 것을 고려해 본다.
- 객체지향에서 책임이라는 개념이 있는데 어떤게 책임을 가질지 정하는게 어려운거 같다.
- 위치 클래스를 만드는 것도 있지만 Enum으로 만들어서 가질 수 있는 위차를 계산하는 방법이 존재.
- 새로줄에 있는 Pawn을 계산하는 연산에서는 Col major로 구조를 짠 것이 도움이 된 것 같았다.
- 과연 움직일 수 있을 지 없을 지 결정하는 것이 어려워 보인다.
- 현재 주어진 미션부터 잘 수행하자.
- 체스보드의 위치를 Position이라는 객체로 관리하는게 좋다.
- 위치는 인덱스 벗어나지 않도록 유효성 검사 필요한데 Board에서 매 메소드마다 위치 유효성 검사를 하게 된다면 중복 코드가 많아지고 응집도가 낮아진다.
- Poistion이라는 별도의 클래스를 만들어서 생성시에 위치 유효성 검사를 하게 하고 매개변수로 Position을 받도록 한다.
- Position 클래스를 Enum 클래스로 선언 vs 일반 클래스로 선언
- Enum으로 사용하면 Position 값 중 하나만 가질 수 있도록 해서 타입 안정성을 제공하고, Enum은 상수 객체이기 때문에 같은 위치를 나타내는 경우 같은 객체를 사용하도록 해서 메모리를 효율적으로 사용할 수 있다.
- 일반 클래스를 사용하는 경우 객체를 생성할때마다 유효성 검사 로직을 실행해야해서 성능 상의 비용이 발생할 수 있다.
- Board를 초기화를 할 때 Piece가 존재하지 않는 칸도 Piece.createBlank() 메소드를 통해 관리하는게 좋은 이유?
- NPE를 방지할 수 있다. 기물이 없는 칸도 PieceType객체가 존재하는 것이 보장되기 때문에 따로 Null 체크 없이 객체에 대해서 함수를 호출할 수 있다.
-
board 전체 기물의 상태를 볼 수 있는 체스판 init 어떻게 구현할 것인가?
- 초기에 Blank 기물을 만들고 위치에 따라 정의된 기물의 속성을 주입하는 방법
- board 초기화 시에 위치에 맞는 기물들을 만드는 방법.
기존 구현된 코드에 따라 방법을 선택하는 것도 좋아보인다.
-
Rank 클래스를 사용하는 이유? Rank 별로 점수 계산하기 쉽고 가독성이 좋은 것 같은 의견 존재.
-
기물의 이동의 경우 누가 책임을 가질 것인지?
- board 클래스에서 일괄적으로 관리하는 방법 → board가 기물의 상호작용을 처리를 위해 존재하기 때문에 board가 가져야할 책임이라는 의견 존재.
- piece 클래스에서 좌표 속성을 갖게 하는 방법 → 결국 board에서도 기물들의 위치를 변경해주어야 하므로 위치 데이터가 중복으로 존재하는 문제가 발생