우아한 테크코스 프리코스 2주차
2주차 미션 깃허브
2주차도 1주차와 같이 진행되었다. 다만 개인적인 사정으로 인해 1주차에 비해 시간을 많이 쓰지는 못해서 조금은 아쉽다. 여하튼 이번 주차에 고민했던/적용했던 부분은 다음과 같다.
- MVC 패턴의 적용
- 입력값 검증
- 클래스 쪼개기
- 테스트 코드 작성
저번 주차 회고에서도 썼듯이, 객체를 쪼개는 부분에 있어서 너무 객체를 큰 단위로만 나눴던 것 같은 아쉬움이 있었다. 그래서 이번에는 View단을 따로 분리하면서 MVC패턴을 적용해서 코드를 작성했다.
MVC 패턴의 적용
MVC 패턴은 디자인 패턴중에서도 가장 기본적이고 유명한 패턴이 아닐까? 싶다. M(odel)-V(iew)-C(ontroller)로 이루어져있는 패턴으로, Model과 View 사이에 Controller가 위치하여 둘이 상호작용 할 수 있도록 한다. 즉, View<->Controller<->Model의 방식으로 상호작용하는 것이다. Model은 당연히 데이터, 객체이고 View는 밖으로 보이는 것, UI(콘솔)이라고 할 수 있겠다. 이때 Model과 View는 서로에 대해 알지 못해야하고, Controller만 Model과 View에 대해 알아야한다. 그래서 다음과 같이 객체를 쪼갰다.
- Model
- Car
- Game
- RandomNumberGenerator
- Controller
- Controller
- View
- InputView
- OutputView
이 외에는 상수들을 저장한 Constants 클래스가 있었다. MVC 패턴을 적용하면서 Controller단의 역할에 대해 고민이 생겼는데, 이번주차 미션은 게임을 사용자가 입력한 n번의 스테이지만큼 진행해서 최종 승리자를 찾아 출력하는 형식이었다. 이때 View단은 입력/출력, Model은 차, 랜덤 숫자 생성기(게임 진행에 필요)인 것 까지는 쪼갰는데, 그렇다면 스테이지별로 진행되는 '게임'은 별도의 Model 객체로 쪼개야 할지, 아니면 Controller단에서 한 번에 게임을 진행해야할지에 대한 고민이 생긴 것이다. Controller단에서 게임 진행을 맡게되면 Controller단의 일이 많아지고, 별도의 model 객체 Game을 생성하게 되면 객체간의 결합도가 너무 높아지는 것이 아닌지에 대한 고민이었다. 결론적으로는 Game 객체를 생성했는데, 이렇게 하니 Controller단의 역할이 간결해졌지만 또 Game의 역할이 많아진 것 같기도 하다..🤔 역시 설계는 해도 해도 어려운 것 같다.
입력값 검증
입력값 검증을 어디에서 해야할지에 대한 고민은 저번주차에도 했지만, 이번주차에서도 여전했다. InputView는 입력을 받는 역할만 할 것인지? 아니면 검증을 하는 역할까지 할 것인지?에 대한 고민이었다. 결론적으로 기본적인 형식상의 검증은 View에서 하고, 해당 값의 조건에 대한 검증은 각 객체에서 하는 것으로 했다.
클래스 쪼개기
위에서 했던 얘기긴 하지만, 클래스를 쪼개면서 객체간의 의존성, 결합도에 대한 고민을 하게 됐다. 막연히만 알고있던 부분이기도 해서 이리저리 자료를 많이 찾아봤지만 크게 와닿지는 않았다. 추후에 우아한 객체지향 영상을 한 번 보고 공부해보려고 한다. 객체지향은 정말 기본이지만서도 동시에 공부하면 할수록 더 어려운 개념인 것 같다.
테스트 코드 작성
이번 주차는 TDD를 적용해보겠다고 다짐했지만... 개인적인 사정으로 인해 시간이 없었던 탓에 구현할 시간이 부족해 이번에도 TDD를 적용하진 못했다🥲. 어쨌든간에 테스트코드를 작성은 했다.
이번 주차에는 콘솔 입력을 활용하는 테스트에서 테스트 메서드가 2개면 2번째로 실행되는 메서드는 매번 오류(No line found)가 나고, 각 메서드를 개별로 실행하면 오류가 나지 않는 상황이 발생했었다. 이전 주차에서는 딱히 발생하지 않았던 오류라서 멘붕이 왔는데, Console.readline() 내부 코드를 확인해보니 static으로 Scanner을 활용하고 있어서 맨 처음 new Scanner(System.in)으로 생성시 System.in으로 들어가는 InputStream이 Scanner의 Buffer에 저장되고, 그래서 새로운 setIn()을 해줘도 값을 읽어올 수 없을뿐만 아니라 이미 모든 값을 읽었으니 no line found라는 오류가 발생하는 것이다. (이 부분에 대해서 처음에는 명확하게 이해가 되지 않아 Scanner, System 내부 구현을 확인하면서 공부해봤다.) 그래서 Console.close()를 매번 호출해줘서 Scanner를 닫아준 후에 새로 생성해줘야 setIn 해준 값을 토대로 테스트를 할 수 있는 것이다!
그리고 이번 주차에서는 ParameterizedTest를 활용해서 손쉽게 여러 파라미터 값으로 테스트를 돌릴 수 있었다. 나름대로 저번 주차보다는 테스트 케이스를 추가한 것 같은데, 아직은 부족한 것 같아서 다음주에는 테스트 케이스를 더 다양하게 해볼 생각이다.
기타
이번 주에 enum을 활용해보려고 했는데, 아쉽게 이건 하지 못했다. 다만 stream의 경우 우승자를 찾는 코드에서 활용해볼 수 있었다! 이번 주차에도 제출이 모두 종료된 후에 다른 분들의 코드도 둘러보며 더 공부해봐야겠다. 그리고 저번주나 이번주나 확실히 java 언어 자체에 대한 공부를 더 해봐야겠다는 생각을 하게 됐다..🧐 프리코스가 끝나면 제대로 더 공부해봐야겠다.
