4주차 미션 요약 - 다리 건너기 (feat. 오징어 게임)
기능 요구사항
-다리는 왼쪽에서 오른쪽으로 건넌다
-위칸 아니면 아래칸 둘 중 하나로 건너야 한다.
-다리를 생성할 때 건널 수 있는 칸(맞춰야 하는 칸은) 0과 1중 무작위 값을 이용해서 정한다.
0은 아래칸 1은 위 칸이 건널 수 있는 칸이 된다.
-다리가 생성되면 플레이어가 이동할 칸을 선택
이동할 때 위 칸은 대문자 U, 아래 칸은 대문자 D를 입력한다.
이동한 칸을 건널 수 있다면 O로 표시한다. 건널 수 없다면 X로 표시한다.
-다리를 끝까지 건너면 게임이 종료된다.
- 다리를 건너다 실패하면 게임을 재시작하거나 종료할 수 있다.
재시작해도 처음에 만든 다리로 재사용한다. (기존에 설계된 다리 그때 그때 부여x)
게임 결과의 총 시도한 횟수는 첫 시도를 포함해 게임을 종료할 때까지 시도한 횟수를 나타낸다. - 사용자가 잘못된 값을 입력할 경우 IllegalArgumentException를 발생시키고, "[ERROR]"로 시작하는 에러 메시지를 출력 후 그 부분부터 입력을 다시 받는다.
입출력 요구 사항
입력
- 자동으로 생성할 다리 길이를 입력 받는다. 3 이상 20 이하의 숫자를 입력할 수 있으며 올바른 값이 아니면 예외 처리한다.
- 라운드마다 플레이어가 이동할 칸을 입력 받는다. U(위 칸)와 D(아래 칸) 중 하나의 문자를 입력할 수 있으며 올바른 값이 아니면 예외 처리한다.
-게임 재시작/종료 여부를 입력 받는다. R(재시작)과 Q(종료) 중 하나의 문자를 입력할 수 있으며 올바른 값이 아니면 예외 처리한다.
출력
- 게임 시작 문구
- 게임 종료 문구
-이동할 수 있는 칸을 선택한 경우 O 표시 ,이동할 수 없는 칸을 선택한 경우 X 표시
-다리의 시작은 [, 다리의 끝은 ]으로 표시
-다리 칸의 구분은 |(앞뒤 공백 포함) 문자열로 구분
-현재까지 건넌 다리를 모두 출력
-예외 상황 시 에러 문구를 출력해야 한다. 단, 에러 문구는 "[ERROR]"로 시작해야 한다.
InputView 클래스
다리사이즈, 움직임, 동작 명령 등 입력값을 받아서 넘겨주는 클래스
OutputView 클래스
콘솔창으로 결과를 보여주는 클래스
BridgeGame 클래스 (패키지 , 반환타입, 인자 변경가능 + 메소드 추가 또는 변경 가능 )
게임에서의 동작과 재실행을 담당
BridgeMaker 클래스 (필드변경 불가 , 메서드 시그니쳐 반환타입 변경 불가)
입력값을 통해 받은 크기 만큼 다리를 만든다.
BridgeRandomNumberGenerator 클래스
랜덤값의 추출
MVC 패턴
https://tecoble.techcourse.co.kr/post/2021-04-26-mvc/ <mvc 패턴에 대해서 '
https://dalpaeng00.tistory.com/83 < mvc 패턴 DAO와 Service 까지 전체적인 흐름에 대한
https://tecoble.techcourse.co.kr/post/2021-04-25-dto-layer-scope/ < DTO에 대해서 DB가 없으니까 static으로 정적으로 관리해야 데이터 운반을 할 수 있을 거 같다. 이 부분에서도 이게 옳은걸까 되게 고민되었음..
service 와 controller등 구분을 통해 요구사항 충족하려고 노력했고 mvc 패턴에 대한 이해도가 낮음을 깨달았고 중점적으로 보았다.
객체 지향
게터와 세터사용하다가 예전에 오브젝트 엘레강스 책에서 게터와 세터는 객체지향적으로 좋지 않은 방식이라고 들어서 객체를 메시지처럼 운용해보려고했는데 너무 어렵다.. 자율적인 책임이라 ...
https://techblog.woowahan.com/2502/ <<객체지향에 대해서 정리한 좋은 글이다. 찾다보면 괜찮은 글은 다 우아한 형제들 기술블로그다.
리팩토링
리팩토링을 위해서 while 문 탈출과 if 문끼리의 정리를 시작했다.
https://zzang9ha.tistory.com/307 > 이 블로그 참고
소감문
미션에 방향: 요번 미션에서 제일 중요하게 잡았던 점은 MVC패턴으로 만드는 것이었습니다. service와 DTO 등 개념을 다시 공부하게 되었고 데이터를 운반하는 과정에서 DB나 프레임워크 없이 깔끔하게 옮길 수 있겠다 싶어 정적인 변수들로 데이터를 각 과정마다 담아서 옮기자 생각하고 미션을 진행하던 중 엘레강스 오브젝트 책과 여러 객체 지향적인 정보 속에 static과 게터와 세터는 객체지향적으로 좋지 않은 방식임을 깨닫고 공통 피드백에 따라 객체를 객체 답게 메세지를 담아서 운용하기 위해 방향을 바꾸었습니다.
예외 : 이어서 구현을 한 뒤 입력, 각 기능 , 기능종합운용 등 제가 나눠 놓았던 구조 속에서 예외를 어느 시점에 적용하는 것이 가장 깔끔할까 고민하고 공부해보는 시간이었습니다. 또한 예외를 처리하는 시점에 재귀처리를 했어야 하는데 이를 찾아보고 공부하면서 꼬리재귀함수와 재귀함수의 스택오버플로우에 관련한 글을 보고 또 하나 배워갔습니다.
MVC패턴 관련해서 느낀 점: MVC패턴으로 뭔가 만들어 나가려 하는 시도 중 프레임워크 제어가 없이 스스로 흐름을 만드는 과정에서 남들에게 어떻게 해야 더 좋은 구조로 다가갈 수 있을까 고민해보고 자료를 찾아보는 시간이었습니다. 또한 프레임워크를 사용하며 공통적으로 가져가는 구조가 프로그래밍하는 많은 사람들에게 유지보수에 용이함을 가져다준다고 느꼈습니다.
마지막으로 코드를 10라인 이하 조건으로 인해 끝없이 분리하며 리팩토링 하는 과정에서 메소드의 역할들이 분명해짐을 배웠습니다.
