본문 바로가기

회고

우아한테크코스 1주차 프리코스 회고록(숫자 야구)

728x90

개요

우아한테크코스의 프리코스가 끝났다.

구현한 코드와 코드 리뷰를 참고하여 회고를 남기려고 한다.

 

1주 차에서 MVC 패턴으로 설계했고, 객체 지향적 설계에 가장 많이 집중했다.

또한 Model이 View에 관여하지 않게 하기 위해 신경을 많이 썼다.

 

구현

위 다이어그램은 Intellij에서 제공하는 각 클래스의 의존성을 보여주는 다이어그램이다.

역할

주요 객체에 대한 역할은 아래와 같다.

Controller

GameController

전체적인 게임의 진행을 담당한다.

  • 유저에게 보여줄 메세지를 출력하거나 입력을 받을 때는 View에게 요청
  • 게임 진행에 필요한 작업은 Model에게 요청

View

입출력을 담당한다.

  • InputView는 입력을, OutputView는 출력을 담당한다.

Model

GameContinueNumber

게임을 계속 진행할지 여부를 결정하는 역할을 한다.

  • 정해진 1 혹은 2의 값을 갖는지 유효성 검사
  • 게임을 계속할 수 있는지 판단

Opponent

상대(컴퓨터) 역할로 사용자의 턴마다 숫자를 비교하고 결과를 전달한다. 

  • 숫자들을 생성하는 것을 생성기에 요청
  • 유저의 숫자들을 받고 결과를 계산

UserNumbers

유저의 입력으로 숫자를 생성, 이에 대한 유효성 검사

 

GuessResult

각 유저 턴의 결과를 계산한다.

  • 스트라이크 카운트를 올린다.
  • 볼 카운트를 올린다.
  • 낫싱인지 판단한다.

배운 점

앞서 기록했던 MVC 패턴과 전략 패턴에 대해 고민해 보고, 적용해 볼 수 있었다.

 

[Design Pattern] 전략 패턴(Strategy Pattern)(1)

객체의 책임을 다양하게 구현할 수 없을까? 개요 객체의 책임을 정의하고, 그 책임을 수행하는 방법을 다양화한다. 객체 지향의 세계는 객체들의 협력으로 이루어진다. 각 객체는 본인의 책임

choi-records.tistory.com

 

[Design Pattern] MVC 패턴 (1)

각 객체들의 설계를 고려하기 전 어플리케이션의 큰 구조를 어떻게 잡으면 좋을까? 개요 우테코 프리코스 미션에서 콘솔 어플리케이션을 구현하는 1주 차 미션을 진행했다. 콘솔을 통해 입력을

choi-records.tistory.com

 

객체 지향

이외에도 객체 지향적 설계를 하기 위해 설계할 때 고민을 많이 했던 것 같다.

본 게임에서 주요 구성요소가 객체로 분리되었는지, 동시에 자율성을 가지고 있는지 많이 고민해 봤다.

 

그 예로 GameContinueNumber 객체는 원래 그저 숫자였다.

하지만, 숫자임에도 게임의 시작 여부를 판단한다라는 역할이 있었고, 유효성 검사도 필요했기 때문에 객체로 분리했다.

Test Fixture

테스트 코드는 Model 객체의 유닛 테스트만 작성했다.

이 과정에서 UserNumber과 Opponent 객체를 테스트할 때, 공통적으로 UserNumber를 생성하는 로직이 필요했다.

두 유닛 테스트에서 공통적인 생성 메서드가 필요한 것이다.

 

이때 좋은 방법이 있는지 알아보다가 Test Fixture라는 개념을 알게 됐다.

중복되는 로직을 한 곳에 고정하는 개념이다. 때문에 중복 로직에 대한 어플리케이션의 변동 사항이 있을 경우, Test Fixture만 수정하면 된다. Test Fixture 없이 위 생성 메서드가 많은 곳에서 중복된다면, 생성 로직이 변경됐을 때 모두 수정해야 하니 번거로웠을 것이다.

 

Test Fixture를 이용해 생성 메서드를 효과적으로 한 곳에서 관리할 수 있었다.

아쉬웠던 점

코드 리뷰를 받으면서 왜 OutputView의 메서드를 모두 static 메서드로 사용했는지에 대해 질문을 받았다.

객체는 협력 관계 내에서 적절한 행동을 해야 하는데 협력 관계보다 객체 자체의 행동에 집중했던 것 같다. 객체 지향적으로 설계하려고 노력했음에도 객체 자체의 행동에 집중해 오직 간편함 때문에 그 역할을 모호하게 하고, 유연성을 저하시킨 것 같아 아쉽다.

 

또한, Opponent 객체에 대해 유효성 검사를 하지 않은 점도 조금 아쉽다.

물론 본 어플리케이션에서는 중복되지 않도록 랜덤으로 리스트를 생성하지만, 생성기 역할을 분리해 Opponent 객체 생성 방법을 다양화했으니 생성하는 숫자 리스트에 대해 그 유효성을 검증하는 로직도 필수적으로 필요했던 것 같다.

 

마지막으로 입력에 대한 예외 처리가 많이 부족했다는 부분이다.

객체 지향적 설계에만 너무 집중한 나머지 가장 중요한 유저 경험에 소홀했다는 것을 뒤늦게 깨달았다.. 

코드

 

GitHub - ChoiWonYu/java-baseball-6

Contribute to ChoiWonYu/java-baseball-6 development by creating an account on GitHub.

github.com

 

728x90