-
Notifications
You must be signed in to change notification settings - Fork 53
[이예진] 사다리 게임 구현 (1-5단계) #66
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: yaevrai
Are you sure you want to change the base?
Conversation
import org.junit.jupiter.api.DisplayName; | ||
import org.junit.jupiter.api.Test; | ||
|
||
public class LadderTest { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AssetJ를 통해 가독성이 좀 더 나은 테스트 코드를 작성했습니다!
미션을 진행하면서 학습테스트의 복습 필요성을 느낍니다 !
for (Boolean point : points) { | ||
System.out.print("|"); | ||
printLine(point); | ||
public void draw() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Line이란 객체에게 사다리 라인을 만드는 책임을 부여했는데요,
라인 생성 == 사다리 출력이 되는 부분이라 이 부분이 view 객체로 가야하나? 라는 생각이 들었습니다.
결과적으로는 Line클래스 내에서 처리하는 게 어떻게 라인을 생성해야하는 지에 대한 비즈니스 로직을 알 수 있고, 좀 더 명확해 보인다고 생각했습니다 😅
public class Results { | ||
|
||
private final Participants participants; | ||
private final List<String> results; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
List results 게임 결과는 사용자에게 입력 받은 값을 그대로 출력해주는 역할 그 이외의 것을 하지 않아
일급컬렉션을 만드는 대신 List로 필드 선언을 했습니다. 일급 컬렉션으로 만드는 게 더 나은 선택이었을까요?
아직 기준이 모호한 듯 합니다.. ㅎㅎ
private final List<String> results; | ||
private final Ladder ladder; | ||
|
||
public GameSetup(Participants participants, List<String> results, Ladder ladder) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LadderGame
클래스에서 play()
에서의 메서드 길이를 줄이기 위해서 구현 후에 게임 관련 정보를 담는 커맨드 객체 GameSetup
를 만들어서 개선을 했는데요. 애초에 LadderGame
역할 분배가 더 이루어졌으면 메서드 길이를 줄이기 위한 목적으로 객체를 굳이 만들지 않아도 되었을까? 라는 생각은 들었는데 어떻게 개선해야할지 방도가 잘 생각이 안났습니다🤣 이전 미션에서도 그렇고 LadderGame
같이 시작점이 되는 메서드가 여러 역할을 갖는 것 같은데, 또 한편으론 시작점이기 때문에 여러 진행 포인트가 합쳐저 있는게 당연하지않나? 라는 생각도 들어요. 제 질문이.. 잘 이해되실지 모르겠습니다 ㅜㅜ 글렌이라면 어떻게 하셨을 거 같은지 궁금합니다!!
리뷰
안녕하세요 😊 이번 미션도 재미있게 구현했습니다..! 말씀해 주셨던 대로 사다리를 처리하는 게 쉽지않았어요 ..핳
이번에는 먼저 코드를 작성하기 보다 생각을 한 후에 구현을 하는 방향으로 진행해봤습니다..! 그리고 미션의 기본 요구사항을
객체지향 생활체조 원칙
이라고 하는 걸 알게됐습니다🙌 이 원칙을 무의식 중에 놓치는 경우가 있었는데 (특히 depth 처리요..ㅎ)이번 학습테스트 주제이기도 한 함수형 메서드를 통해서 쉽게 개선할 수 있는 방향을 찾은 것 같았습니다.
또 일급 컬렉션 을 제대로 활용해보려 노력했는데요.. 하지만 여전히 고민되는 부분들이 많네요..😅 지난번 팁으로 알려주신 getter의 사용이 줄었는 지를 통해 객체의 책임이 잘 분배되었는지 신경 썼는데요. 아직도 스스로 명확하게 분리하고있단 자신은 없습니다. 하핳
질문
LadderGame 클래스가 현재 너무 많은 책임을 가지고 있는 것 같기도한데요..! 게임의 시작점이 되는 부분이라 총괄 책임을 진다는 느낌으로
여러 책임을 모아뒀는데 어떻게 보이시나요??
이번 미션에서의 객체간의 책임 분배는 어땠을까요!?
enum을 사용하기위해 ResultType 객체를 생성해 전체 참가자/개인으로 분리하는 부분을 고정시켰습니다. 그런데 필드로 선언한 value값을 사용하지 않기도 하고, 출력을 할 때 한번 선택을 위해 enum을 생성한 게 올바른가? 라는 고민을 했어요. 아니면 이번에 다른 부분에서 enum을 활용할 수도 있었을까요?
이런 부분들이 계속 고민이 됩니다.. 이번에도 좋은 피드백 부탁드립니다! 🙏
기능 설명
Controller
Model
GameSetup
Ladder
Line
Name
Participants
Results
ResultType (enum)
View
InputView
OutputView