[사다리 게임] 베디 미션 제출합니다 #25
Conversation
split(string numbers) 메소드가 문자열을 받아서 구분자를 기준으로 문자열을 분리해서 리턴. 만약 문자열 앞에 커스텀 구분자가 있으면 커스텀 구분자로 분리
양수를 Positive.class 를 통하여 포장, StringCalculator.class 의 calculate 메소드를 통하여 입력받은 문자열을 숫자로 변환하여 더해서 반환해준다.
Value Object 는 불변이 특징
Player.class 생성 및 이름 길이에 따른 유효성 검사
입력받은 문자열을 쉼표(,)를 기준으로 구분후 List Player를 생성해 준다.
validateName 메소드를 추출해서 이름의 유효성 검사
Player들을 관리하는 일급 컬렉션 사이즈 체크를 위한 validate 메소드 추가
사이즈가 0인지, subLine이 겹치는(연속 true) 유효성 검사
각각의 Line에 대해서 subLine의 List를 random하게 생성
- 높이와 사용자 수에 따른 유효성 검사 - SubLineRandomGenerator로 부터 생성된 subLine의 List를 가지는 Line의 List를 생성
- subLines의 수가 countOfPlayer보다 많이 생성되는 경우 - true가 연달아 삽입되는 경우
Ladder.class 와 GamePlayers.class 를 가지고 게임을 관리
console game 진행 추가
- GameResult.class: 실행결과 관리 - GameResultGenerator.class : 입력에따라 GameResult.class 를 생성
List<Line> 를 생성하기 위해 LineGenerator.class 사용
결과를 보고 싶은 사람은?에서 없는 사람 입력할 경우 없는 사용자입니다. 출력
Player의 name에 all 이 들어올 경우 예외로 처리
결과 입력시, 없는 사용자일 경우 상수로 추출
Set을 이용한 허용될 수 없는 이름검증
| @@ -0,0 +1,20 @@ | |||
| package calculator; | |||
|
|
|||
| public class Positive { | |||
| public class LadderConsoleApp { | ||
| public static void main(String[] args) { | ||
| LadderGameController ladderGameController = new LadderGameController(); | ||
| ladderGameController.run(); |
There was a problem hiding this comment.
굳이 Controller를 별도로 추가하지 않고 main() 메소드를 controller처럼 사용해도 되지 않을까?
| } | ||
|
|
||
| private String inputNames() { | ||
| return InputConsoleView.inputNames(); |
There was a problem hiding this comment.
굳이 이런 부분까지 메소드로 분리할 필요가 있을까?
| import java.util.List; | ||
| import java.util.Set; | ||
|
|
||
| public final class GamePlayers { |
| } | ||
|
|
||
| private void validateDuplication(List<Player> players) { | ||
| Set<Player> set = new HashSet<>(players); |
There was a problem hiding this comment.
중복 체크를 위해 Set을 사용한다면 인스턴스 변수를 'List players' 대신 'Set players`로 구현하는 것은 어떨까?
There was a problem hiding this comment.
List를 한 이유가 Player는 필드로 이름만 가지고 있어서 List의 index로 position을 찾기 위해서 한거였는데요.
Player에 position 필드를 추가하고 Set으로 변경 했습니다.
| import java.util.HashMap; | ||
| import java.util.Map; | ||
|
|
||
| public class GameResult { |
There was a problem hiding this comment.
GameResult에 Ladder를 전달하기 보다 Map<Integer, Integer> result = ladder.play()와 같은 실행 결과만을 GameResult에 전달하는 것은 어떨까?
또는 GameResult result = ladder.play(gamePlayers, playerRewards)와 같이 구현하는 것은 어떨까?
There was a problem hiding this comment.
네 다시 생각해보니 이렇게 하는게 좋을거 같아서 반영했습니다.
|
|
||
| private boolean isRight(int index) { | ||
| return index < subLines.size() && subLines.get(index); | ||
| } |
There was a problem hiding this comment.
수업 중에 다룬 Point 또는 Direction과 같은 객체의 추가를 통해 isLeft, isRight 구현부 조건절을 좀 더 단순하게 구현해 보는 것은 어떨까?
| List<Line> lines = Arrays.asList(new Line(line1.size(), () -> line1), new Line(line2.size(), () -> line2)); | ||
| ladder = new Ladder(lines.size(), gamePlayers.size(), () -> lines); | ||
|
|
||
| gameResult = new GameResult(ladder, gamePlayers, playerRewards); |
There was a problem hiding this comment.
GameResult 테스트를 위해 데이터 초기화 과정이 너무 복잡하다.
여기서 힌트를 얻어 GameResult의 구조를 좀 더 개선해 볼 방법이 없는지 고민해 보면 좋겠다.
파라미터 받던 것을 안받는 것으로 수정.
subLine(가로줄)을 Direction으로 변경해주면서 기존의 SubLineGenerator와 LineGenerator는 삭제하고 List<Direction>를 생성해주는 DirectionsGenerator를 생성해주고 DirectionsGenerator를 생성해주는 팩토리를 구현. 팩토리 패턴으
Player에 position을 추가해줘서 List의 인덱스로 position을 찾을 필요가 없어져서 중복 제거 차원에서 Set으로 변경
GamePlayer와 PlayerRewards로 게임의 결과를 구해주는 Ladder.play()
기존에는 List<Player>를 반환 해서 그 값으로 외부에서 Players 인스턴스를 생성했지만, 더 복잡한거 같아서 한번에 Players 인스턴스 생성 후 반환하게 변경
일급컬렉션의 컬렉션은 불변이 보장되어야 하는데 그대로 return 해주면 같은 주소를 참조한다. 그래서 외부에서 값 변경시 일급컬렉션의 컬렉션도 같이 변경 되서 변경
|
Direction을 추가하니까 연쇄적으로 변경되는 코드들이 정말 많아서 고생했습니다. '차라리 엎어버리고 새로 하고 싶다'라는 충동도 느끼고 이래서 클래스 사이의 결합도가 낮아야 한다는 것을 뼈저리게 느낄 수 있었습니다. 그리고 기존에 있던 Generator를 조금 더 수정해서 팩토리 패턴으로 구현했는데요. 구현하고 나서 객체지향 강의를 보니까 팩토리 패턴을 사용하면 유연해지지만 이른 추상화는 추천하지 않는다고 하더라고요.
사실 지금 굳이 할 필요는 없었는데 나중에 확장도 생각하면서 설계를 하면 좀 더 유연하게 하지 않을까 하는 마음으로 구현했습니다. 포비님은 어떻게 생각하시나요? 현재는 팩토리패턴을 사용할 필요가 없으니 미리 하지 말고 나중에 기능이 추가될 때 구현하는 게 더 나을까요? |
|
@dpudpu |
지적 많이 해주시면 감사하겠습니다.